From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0A0D21AAC9 for ; Mon, 14 Apr 2025 16:14:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744647280; cv=none; b=KzKD/Zy5kdNlzo/WJwSEQehOE6xD536vU59Df8pxlkiFgyseUcO6J8nm60aAGu6SQji4TDg9P9zyMOJ6JVxGPwjK2gA/DjlOeWKKM3JJD+oDEoQi4PYELTrBGaEbiYhhT33HqS2Y/aCufSvKILyjm8D0+2hPdHGQ/nM5DI47nqc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744647280; c=relaxed/simple; bh=HYX44cAlUGzz06XcvpeBhoArLNi5ITgcDrl75RRaVDQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eAvML/dJO8zT1YBKoqAXkZQ8uDIqvmG6ML7ColxttYqb5gOCNhSWrEHWyxUAHgN6ay0IM0rVbAMrA9zOSeSLJ+LMH20eXvjZx7Ok0T9JnwhoqBsx1j5FP+J4t5UNX6LSN2UxDWiIA4XQM6uxOQWj1HkkLV5v39Y2QVs2qaBdzPA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=moGcroy4; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="moGcroy4" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=l3fsDK/SgDcv/8e9T9UGtpM8KqCUafg3BsX/jJbq+Ro=; b=moGcroy4VlDdJnf4fJKzGuExKs G/14o0wLh5/tpW/4RJHnU5Zw1lD0Kyl8tHUHVeOMJHVq69atSwMkHxXi6TmKogHUVvxlkalLNj6jT QhgDdYlOE+MmIrLLoZSkhz4LnbUAEBJFfKngnldUChErdOugIkNLAJQ9lFFo8tNpzD7OvlaUBVIvX hskvqt3t/MTbx1gzUDIX4pZYI6W+cPEDqWi9NyHtFMZhHOF3vfxe2vvVRTnGy2OobegkmISMTugYU g6g+IxMx9EN2SQtvxV5ixzwGaClO+G3vnnqFAeQDEoY7ABec5tUoz2b7BLzw/w7Mp49Z7nwETTQor aKp38cKw==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1u4MSA-000000092u9-16ic; Mon, 14 Apr 2025 16:14:34 +0000 Date: Mon, 14 Apr 2025 17:14:34 +0100 From: Matthew Wilcox To: James Bottomley Cc: Miklos Szeredi , Christian Brauner , linux-fsdevel@vger.kernel.org, Al Viro , Amir Goldstein , Jan Kara , Ian Kent Subject: Re: bad things when too many negative dentries in a directory Message-ID: References: <20250411-rennen-bleichen-894e4b8d86ac@brauner> <2334928cfdb750fd71f04c884eeb9ae29a382500.camel@HansenPartnership.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Apr 14, 2025 at 11:40:36AM -0400, James Bottomley wrote: > On Mon, 2025-04-14 at 15:30 +0100, Matthew Wilcox wrote: > > > If an application does an A:B:C directory search pattern it's > > > usually because it doesn't directly own the file location and hence > > > suggests that other applications would also be looking for it, > > > which would seem to indicate, if the search pattern gets repeated, > > > that the two negative dentries do serve a purpose. > > > > Not in this case.  It's doing something like looking in /etc/app.d > > /usr/share/app/defaults/ and then /var/run/app/ .  Don't quote me on > > the exact paths, or suggest alternatives based on these names; it's > > been a few years since I last looked.  But I can assure you no other > > app is looking at these dentries; they're looked up exactly once. > > I got that's what it's doing, and why the negative dentries are useless > since the file name is app specific, I'm just curious why an app that > knows it's the only consumer of a file places it in the last place it > looks rather than the first ... it seems to be suboptimal and difficult > for us to detect heuristically. The first two are read only. One is where the package could have an override, the second is where the local sysadmin could have an override. The third is writable. It's not entirely insane. Another way to solve this would be to notice "hey, this directory only has three entries and umpteen negative entries, let's do the thing that ramfs does to tell the dcache that it knows about all positive entries in this directory and delete all the negative ones". I forget what flag that is.