From patchwork Wed May 15 09:17:27 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yafang Shao X-Patchwork-Id: 13664921 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47365C41513 for ; Wed, 15 May 2024 09:17:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74DB66B02E9; Wed, 15 May 2024 05:17:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FF186B02F2; Wed, 15 May 2024 05:17:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A05D6B02F3; Wed, 15 May 2024 05:17:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3AC396B02E9 for ; Wed, 15 May 2024 05:17:49 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B2217C137E for ; Wed, 15 May 2024 09:17:48 +0000 (UTC) X-FDA: 82120077816.24.CF7E0FA Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf02.hostedemail.com (Postfix) with ESMTP id E1C5780007 for ; Wed, 15 May 2024 09:17:45 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ReNAHqkA; spf=pass (imf02.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715764665; a=rsa-sha256; cv=none; b=J5E9CTIcDTkfC6BAqG6l6qXFxfY1c1W40K4o09e7AshHa29MFb4TuvkLwKcvbYQxtGb4TM edmbY2mIPd2kDaJZO3bf7Ht19CbL6fYLVJ5lRKoJrae1YvvQ/yzhdXCoFCgLZe0+QzEQ45 JMv0tbtbv7jftCj8GgZCdPWj2JQ3eAM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ReNAHqkA; spf=pass (imf02.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715764665; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5Wv8rV2tKPThsseCMW82u6ARIGWeqVn1KtBaNU4oLcc=; b=YUWl2tmy5RX4k0defOAvf5YFL4EsEeuhPAPhuS5yi0nuTIn5EQ07GeouuhCnRX3Z+68HXm ulz18cQZABO6kOvBtWRw/ZvelDbesBnjRHZImp+SBZdW5iPYBXwlb9d8XTW4XiCaGyTedH ayaextLAfKOEHYhk8CEQ5XPXyzt5qgs= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1ed0abbf706so48753235ad.2 for ; Wed, 15 May 2024 02:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715764665; x=1716369465; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5Wv8rV2tKPThsseCMW82u6ARIGWeqVn1KtBaNU4oLcc=; b=ReNAHqkAT6ejpKhLj9V9+Wnwr/oN74DTXVe9XfRnSwWa96L3T6VMN/ARzKp1wXIKbp qe6nY2xbq3BlHcmA4sH0ldZL4+E9PQChMDwGwqaXSyQgoPNT2mu9oQrFLfRYarSWXU1r MJze4HeBlEvirhzkPYDWRAdxhYCTL+2mx2Y5lr50Mhbvwn7KNIgf4rGCJQa/qC5f1fLn 95PRhUcHA8QSYBfHNFH7NVFQVOyJ7PlqtV8TWMhMNAMMZudopDLrtr9zUuFGTY2vTTEH Bt4QmHJuEWi+P7jMp1OdHKFW9Fw4Dlg9Y0/v+inQCP/CYbml9UMnGq4Egi6G3WR+OS8b B4IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715764665; x=1716369465; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5Wv8rV2tKPThsseCMW82u6ARIGWeqVn1KtBaNU4oLcc=; b=wjCkrC+/BAvHw4RG2qUZLa8T6EQ+ZhlbIzDLlBLGQ0WKZVcouIiEjpG3eJLDg/KyI6 GtyRCppYj5ykopRtsm8vPhlF6hHj628QKu30BVlC+H29QXI6UdDeTcHvjUjF3rOJqkDv 7HChqYQViwz0FtoWx9Hc6YNUcpMyMVbH6sxUpLR0B8Jy+KMmLE45+HTjORr48XFVPHfJ 90fTqT4lUOeoD/hHbprcAE297y5SNxKJWcGSDwXuKdYH8ZRJwSKsSDVodEW4JPGw5zVS nnixGInjI5IeYD9Ka0LvB23lxp1DUm7gQOwuUGlMLZMiEYkx/2E1phcjlfugvD7U1WeB ZQ7A== X-Forwarded-Encrypted: i=1; AJvYcCWZGLGexDdR19EvTRyLo3TSeMD7gwklQGDNX3mM+lbWqDdkQymraJTJXWZN6txetelVNKAT7EnVzAjTHg5CZWf1Czs= X-Gm-Message-State: AOJu0Yxj1KmY14PMXvTkGOLT8/edI1kRwOTorGi6VyGYqxCjnRx7Rd6E mS8wxpVAsLxfP9WLO/9QgM4jpNM7u3zG1X0xt4J9/Z2BXsKcoIIZ X-Google-Smtp-Source: AGHT+IFtmVf7oEws1uF1l3m/5X3gzrEYi5mE17gV2Q6owMBXhDKxbWShPbXhK8zPO76YBGJxCnbDkQ== X-Received: by 2002:a17:902:ec8b:b0:1eb:1129:7f15 with SMTP id d9443c01a7336-1ef4404a272mr202174455ad.46.1715764664621; Wed, 15 May 2024 02:17:44 -0700 (PDT) Received: from localhost.localdomain ([39.144.45.254]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1ef0bf30fb1sm113304135ad.177.2024.05.15.02.17.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 May 2024 02:17:44 -0700 (PDT) From: Yafang Shao To: torvalds@linux-foundation.org Cc: brauner@kernel.org, jack@suse.cz, laoar.shao@gmail.com, linux-fsdevel@vger.kernel.org, longman@redhat.com, viro@zeniv.linux.org.uk, walters@verbum.org, wangkai86@huawei.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Matthew Wilcox Subject: [PATCH] vfs: Delete the associated dentry when deleting a file Date: Wed, 15 May 2024 17:17:27 +0800 Message-Id: <20240515091727.22034-1-laoar.shao@gmail.com> X-Mailer: git-send-email 2.30.1 (Apple Git-130) In-Reply-To: References: MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E1C5780007 X-Stat-Signature: n6te8cnegz311haicxqg9tbrnpr6ratz X-HE-Tag: 1715764665-993914 X-HE-Meta: U2FsdGVkX1+rA4dYDb2mvpn2dbN9YgLi9Lm638E2CGXJzad8/rvo3Lgha5HzEUhxAj9WpImqaGlm62FmKH4B/C5Oybq3kXfM1uWruTwUGyJD5WthXtNYZqW48NAYHVITuPs4oda7AvhFT2Eq3+vaN8dsB9Ht0dAPcMc2cRbhQ4fps6Gz0Tw9EY8HiaxuwIQj5OyGIXadC+mrMNzJy9QuqZ1jOlvb2bP589veBxOU/ynUwTpLgXBkQYXI0vVO3NrqX5CGaFnvvMIiY4eUHq79jGYvUTp93F62VRMXWM1O2QpbC0gbXrXjCbcnYITWJ4Ieq7HlbP+1MZiv9glR0nqJdMCT4R2j4D+mKWwkmmHx6WyLPQYvBDmsfBjdRPxx1Irf2D1PiULK0bqj7oqjuYcqLPPpU6C221ia5VT5Xo48JeS8iA2csi50uDYHwvtflMFQORGQqC2XYzRlpfQJGRVaSulzsePYzUM6vVv4V8M2h+0G3qEAqPovWTWjINeIlJwm10Zc7QOiU5t4Z1mhpimV2efAMuaD5Om9VwvFuNohQzr9L4YDC1Gtt3zKddw8TFbvitoFvV3Ph9g6q0aWmG88E02s1w3noptl3yp48d5PmPfPu2IChyt1jVnprqOOK5aQvpghY6QiGRkrFo0ZzrhP6VKgjSptZouTJVVkO/GAFM4ObgWXzDPjJfe/ZoioxXE+OOIC2piuV7P6DSQOi1dNn4jV2RNW8aV9ATCJVG/EGPMDZOmLvdXuJzA9VNKHcvnWDBBBROMgqK9WtGG1IvYytyAEfAnjRg+R1dF+45nYS/jVm7dhnM3TnE5I/Eyfzqm6NTmXB+1UGQS6Azqf3G7ZaKxxnYSgl0+G/j7oxLRKTWNxL7ny2UccFf1PUDATaug5NPki54Bk8RjV2U45mWG+/QE72d1c19pfQbFmcJnYX2AHgOUFJObTzegKVNemJhkGexyQAEnTR8rOL4ahFaq LpacOvJ7 xN17/BH98LfB2fvI05pQOn2Ve6Lff+b5r8hy/ez4kPLQoLqGDDUolv5YV9QTfYoNJM0b9dPMuju2qMngFc+zeKbAxmDpZfcnyAvfTFBK7zuvHIY0e+YMi5XQwX8z1aHxhiOvFA5IXKS+dS4LDo4/IFnfN1uoalWQ1nLbHs9a/u2HgkYRQpcvijxm06FQcMTJLX5X8HPpUbioPXTQ9mjI5o8QI17ixMNKj+E9GiOBa/7Wb2xgQvDAOkEWSAu4QOCH+PAcrU8/wRBI3RiiwQsy2aV5Lh+nJcUCU00AzyEqQFgUVjhY9AM25Wfaobf4cRGQJc6KpQux/Cjygt1skBr1cNOivdeBmwSf2VYvXePxAHeSRs7AARV2sG/jRSDhRUQmOTatjCXU4UWdIeJzxEyF0lrA1JX7bAzOEyEeRuAQ5y5Xcc++fjRcQcwuDSO7pphuUYcyhvA5vwFD4e+UETl4bFmyInOJNHCDyJ/R87NrN3SJlfr6qwtCaCR4NYGkSbhpZIAdiOqiA1qkzjToGtE1y6gwFhIVi5Zp4slyCVQTvKQvEhIaEa3fU8YabfZ8rkBkrKba8U7BMKRkmXUaQy7S6tgzGnPahC5rrhEGuTt03CiSp0v2XdH48WqPKsr+RGZ4Lydaf1iB3JBS12PpygdHmj/d5ZnTjcX+0HXnlxBGWofrgEgXJCNbQJ/t1nWYzJ+PeKiWGVlyDxH4ChrvW0Vyl5Z2nL/iqT9bodTnW3nQNsjnRdve9jHTvso+aDctYaHuhE0P+nKkwX/46glfq/iq2Jan6EHW0DeppaL2XMlVPPpZp6TSukGRbb1q2u0KYP12FtCFvfL5uzdDrGTSINU4GkJG6YBoQyGWFDRakJRbJiRMnlpwNm8UIztnn4w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Our applications, built on Elasticsearch[0], frequently create and delete files. These applications operate within containers, some with a memory limit exceeding 100GB. Over prolonged periods, the accumulation of negative dentries within these containers can amount to tens of gigabytes. Upon container exit, directories are deleted. However, due to the numerous associated dentries, this process can be time-consuming. Our users have expressed frustration with this prolonged exit duration, which constitutes our first issue. Simultaneously, other processes may attempt to access the parent directory of the Elasticsearch directories. Since the task responsible for deleting the dentries holds the inode lock, processes attempting directory lookup experience significant delays. This issue, our second problem, is easily demonstrated: - Task 1 generates negative dentries: $ pwd ~/test $ mkdir es && cd es/ && ./create_and_delete_files.sh [ After generating tens of GB dentries ] $ cd ~/test && rm -rf es [ It will take a long duration to finish ] - Task 2 attempts to lookup the 'test/' directory $ pwd ~/test $ ls The 'ls' command in Task 2 experiences prolonged execution as Task 1 is deleting the dentries. We've devised a solution to address both issues by deleting associated dentry when removing a file. Interestingly, we've noted that a similar patch was proposed years ago[1], although it was rejected citing the absence of tangible issues caused by negative dentries. Given our current challenges, we're resubmitting the proposal. All relevant stakeholders from previous discussions have been included for reference. Some alternative solutions are also under discussion[2][3], such as shrinking child dentries outside of the parent inode lock or even asynchronously shrinking child dentries. However, given the straightforward nature of the current solution, I believe this approach is still necessary. [0]. https://github.com/elastic/elasticsearch [1]. https://patchwork.kernel.org/project/linux-fsdevel/patch/1502099673-31620-1-git-send-email-wangkai86@huawei.com [2]. https://lore.kernel.org/linux-fsdevel/20240511200240.6354-2-torvalds@linux-foundation.org/ [3]. https://lore.kernel.org/linux-fsdevel/CAHk-=wjEMf8Du4UFzxuToGDnF3yLaMcrYeyNAaH1NJWa6fwcNQ@mail.gmail.com/ Suggested-by: Linus Torvalds Signed-off-by: Yafang Shao Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Cc: Waiman Long Cc: Matthew Wilcox Cc: Wangkai Cc: Colin Walters --- fs/dcache.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 71a8e943a0fa..2ffdb98e9166 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2360,19 +2360,17 @@ EXPORT_SYMBOL(d_hash_and_lookup); * - unhash this dentry and free it. * * Usually, we want to just turn this into - * a negative dentry, but if anybody else is - * currently using the dentry or the inode - * we can't do that and we fall back on removing - * it from the hash queues and waiting for - * it to be deleted later when it has no users + * a negative dentry, but certain workloads can + * generate a large number of negative dentries. + * Therefore, it would be better to simply + * unhash it. */ /** * d_delete - delete a dentry * @dentry: The dentry to delete * - * Turn the dentry into a negative dentry if possible, otherwise - * remove it from the hash queues so it can be deleted later + * Remove the dentry from the hash queues so it can be deleted later. */ void d_delete(struct dentry * dentry) @@ -2381,14 +2379,14 @@ void d_delete(struct dentry * dentry) spin_lock(&inode->i_lock); spin_lock(&dentry->d_lock); + __d_drop(dentry); + /* * Are we the only user? */ if (dentry->d_lockref.count == 1) { - dentry->d_flags &= ~DCACHE_CANT_MOUNT; dentry_unlink_inode(dentry); } else { - __d_drop(dentry); spin_unlock(&dentry->d_lock); spin_unlock(&inode->i_lock); }