On Sat, Jun 17, Neil Brown wrote: > 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. I don't remember exactly, maybe it was remounting instead of unmounting. Although I believe that we should call shrink_dcache_sb() instead of shrink_dcache_anon()+parent() when unmounting. I don't see any reason why we should shrink the dcache with depth-first traversal instead of just killing every unused dentry that we find (not even talking about that DCACHE_REFERENCE handling is nonesense in that case). > But I'm still puzzled as to why a long dcache LRU slows down > unmounting. > > Can you give more details? I think David already answered that. Jan - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
