On Friday June 16, [email protected] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
