From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Re: [patch 0/5] [PATCH,RFC] vfs: per-superblock unused dentries list (2nd version) Date: Sat, 17 Jun 2006 08:25:14 +1000 Message-ID: <17555.12234.347353.670918@cse.unsw.edu.au> References: <20060601095125.773684000@hasse.suse.de> <17539.35118.103025.716435@cse.unsw.edu.au> <20060616155120.GA6824@hasse.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, akpm@osdl.org, viro@zeniv.linux.org.uk, dgc@sgi.com, balbir@in.ibm.com Return-path: Received: from ns1.suse.de ([195.135.220.2]:56983 "EHLO mx1.suse.de") by vger.kernel.org with ESMTP id S1750848AbWFPWZ3 (ORCPT ); Fri, 16 Jun 2006 18:25:29 -0400 To: Jan Blunck In-Reply-To: message from Jan Blunck on Friday June 16 Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Friday June 16, jblunck@suse.de wrote: > On Mon, Jun 05, Neil Brown wrote: > > > I understand that this is where problem is because the selected > > dentries don't stay at the end of the list very long in some > > circumstances. In particular, other filesystems' dentries get mixed > > in. > > No. The problem is that the LRU list is too long and therefore unmounting > seems to take ages. > But I cannot see that the whole LRU list needs to be scanned during unmount. The only thing that does that is shrink_dcache_sb, which is used: in do_remount_sb in __invalidate_device in a few filesystems (autofs, coda, smbfs) and not when unmounting the filesystem (despite the comment). (This is in 2.6.17-ec6-mm2). I can see that shrink_dcache_sb could take a long time and should be fixed, which should be as simple as replacing it with shrink_dcache_parent; shrink_dcache_anon. But I'm still puzzled as to why a long dcache LRU slows down unmounting. Can you give more details? Thanks, NeilBrown