From mboxrd@z Thu Jan 1 00:00:00 1970 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 8377EC25B78 for ; Wed, 22 May 2024 17:14:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DF9B6B0088; Wed, 22 May 2024 13:14:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 98FD46B0089; Wed, 22 May 2024 13:14:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87F656B008A; Wed, 22 May 2024 13:14:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6AE566B0088 for ; Wed, 22 May 2024 13:14:16 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 249E0A5419 for ; Wed, 22 May 2024 17:14:16 +0000 (UTC) X-FDA: 82146680112.17.AA0E7A2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 6F65A180028 for ; Wed, 22 May 2024 17:14:13 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=VBh336lN; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716398054; a=rsa-sha256; cv=none; b=bcIRQYqVqmcJYJDfCgrco7MB1VLPYvGV1iKNXfGjwbdO8cKMMjRraFahY6AbbQOTpBZuVB B1jbek9yE3v9bhxaG8s4DW/cxQiN5Qv0NLK9IgSeUUfggRRMpg1C1k4FPIJgghJHi4v4v1 UnPBrlPlM9MZORmCo2mhAvVQEiv4svA= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=VBh336lN; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716398054; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tTs5GqkH792WkQ5uou1WjI1GQqIun7xt5FNmVzrUoKY=; b=cqUqgbZhx21GfJT+sHHIi2PcyTQksTSe9ldGccrifqKABRMFpKoT8gNBGbTKycL5+LlZlS RCYK8qIy6BzTkdxzDeYrekAKnlUZlsVZWwk46hcfUnucylKCOT2l2XbHYL5r5oOfdvzEss TS2BpdvyNj8uN9hawO8+Uq1fsCp8B2o= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=tTs5GqkH792WkQ5uou1WjI1GQqIun7xt5FNmVzrUoKY=; b=VBh336lNsDVUCmD5sKjJynTTOh g791d7gHmi1Fk0v2aqXU+C+DyODxr3tIORHuNoGSbhfb2slTVoVTl2uFIPrn37YqWi26hN0KsDqw5 2KhmSp9dzPE6HM0kh+R41fRhe5dpes8HAKZWjx6tw8sHax/GhqN7JpQ52k1wurVhMys2G3lgtaNAP SdQxtE6X4eDiXexmnCf0GIyqNKg4hDO5hJdvkRGrRYfTlf/EUctSuaRAb2URt58u+IE9aoCOh50Mv fkyNht8QFQCvA/o06TuCmu/IQoWdWf0GJCCuAZJoCUtsKKsXpe8raiRvAJevNdylYnxyZTPPRp2k+ Ui/x+jiQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9pXJ-00000000rO0-2wvS; Wed, 22 May 2024 17:13:57 +0000 Date: Wed, 22 May 2024 18:13:57 +0100 From: Matthew Wilcox To: Linus Torvalds Cc: kernel test robot , Yafang Shao , oe-lkp@lists.linux.dev, lkp@intel.com, Al Viro , Christian Brauner , Jan Kara , Waiman Long , Wangkai , Colin Walters , linux-fsdevel@vger.kernel.org, ying.huang@intel.com, feng.tang@intel.com, fengwei.yin@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] vfs: Delete the associated dentry when deleting a file Message-ID: References: <20240515091727.22034-1-laoar.shao@gmail.com> <202405221518.ecea2810-oliver.sang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 6F65A180028 X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: 6g4df6ud56zua8ypihb664onew3go316 X-HE-Tag: 1716398053-478485 X-HE-Meta: U2FsdGVkX1/VIrIKCHuPDh/3hO02r3DJd7yytZ5usf8Py1vA58vo+P6FrfkDEWeXawraDD4XNqx3f9/LZzD9JOPvIMggLswoEfkFbbOpg26m7Sr1uhdHrYw7Z2NDXf2gzD79EDcU4+Q0FYdOrzbweHYPZdxOE2zjVl59q8D/Dpys7fFd/mHbWxYyjLkqCEI9it74glj/PgkNM998Xadbs5YDUxThNztVFh/XgrP0zELS7CwpZzHdW0nwMkT+tNTo7Pt9nPs3u6TI4/1gRdHFjwH/oOoDM1vzFMcIE6v4AUa7N3KZbA1weXckrG1SDKunrEMqMeb63FCuiiWK1EtKn4jq62Ntsy/sj9APDtTtAcjYa00zZuPlm1EXAARDYdQ5MaF7jGmeRTwBPl6VvOu1MHHlaIW6YU5gnvhUd21zSxw0JqR4UfEscXzN4Rs48ILyy2Az780K0433chFs0dYrT3Nz+iz770P0DFc3rkPstlAwRXx+PhAyTe4D+na30WtZKzXmErG8NBuzwbwjirjC97h+wIS4b4pnlOiOXauYbIgyvZkZM0Z/vFHobh9VkrbVSZvnbSif+dDnS9oJv/zuIJWQPwvFVdUIDxZVLMpbKANu1ZZOJkzXBCe3fLxv/ABvRL/1fQDbMzdw4dgMcHDR5UvmbZJmhkoVvhPQdlFi1Vh+GI4LkVquKJtKxlKGehQAH70ILMIbi0Ou/0bNJMM3rmJYYQC0Y/ebBNZI/64NPVuGECAA0mOfmex1JJeJutgakCfKYVyMg6YdqaOAMJ7BBRvHFkCTxQIJw4Vs9aq++nfpmxfzZkUf7r9ckW1VkDNIN7kWvjAq0FzgK2DcSY61Je5tMsJILz152ytdqxo2GOzBMHc1OHwCEJj9/AVa+1vylOydgJ8rbHPtzZYYIB2u0UcHBqZeCymXLPRnnpqOXmxuYk6GEy1bFCFjaS2rSkJpas+L0ZyhB3a35KPm6Jj /LQXNFpd oZM2oCmur95H1nBScmxs+0DwblJ1QA++9wXbBpo0QsjyR/uA7ZeXTlfR+61XtJ2p2/kQERtzxci7fQdl6ZS31+AOHrKOcz9KuS0qO2IBlRSy7skGAnH34+1mhvM3vCud9HF7tsy7oqxY4bA8q0tyiWthAYWgwDP/6wD+p8C7Z452W44RisAWn2UeTMHBSdFIIr+wIbxWBh5XmCNhJN8GHOLJnyg== 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: On Wed, May 22, 2024 at 09:00:03AM -0700, Linus Torvalds wrote: > Of course, if you do billions of lookups of different files that do > not exist in the same directory, I suspect you just have yourself to > blame, so the "lots of negative lookups" load doesn't sound > particularly realistic. Oh no. We have real customers that this hits and it's not even stupid. Every time an "event" happens, they look up something like a hash in three different directories (like $PATH or multiple -I flags to the compiler). Order is important, so they can't just look it up in the directory that it's most likely to exist in. It usually fails to exist in directory A and B, so we create dentries that say it doesn't. And those dentries are literally never referenced again. Then directory C has the file they're looking for (or it doesn't and it gets created because the process has write access to C and not A or B). plan9 handles this so much better because it has that union-mount stuff instead of search paths. So it creates one dentry that tells it which of those directories it actually exists in. But we're stuck with unix-style search paths, so life is pain.