On Fri, Feb 14, 2014 at 09:02:30AM -0800, Eric W. Biederman wrote: > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: > > > On Fri, Feb 14, 2014 at 07:49:35AM -0800, Eric W. Biederman wrote: > >> > >> I believe we want both groups of dentries on the s_anon list so that if > >> they remain disconnected when the filesystem is unmounted we can > >> find them and deal with them. > > > > Note it's IS_ROOT(), not DCACHE_DISCONNECTED, that determines whether a > > hashed dentry is on s_anon or not. (See > > 7632e465feb182cadc3c9aa1282a057201818a8c for more detailed > > discussion.) > > Interesting. It remains the case that d_obtain_alias that sets > DCACHE_DISCONNECTED is the only way to get on the s_anon list. You're right, I forgot that. > >From the rest of the conversation below I think what is needed is > d_obtain_alias_root. A function like d_obtain_alias but that does not > set DCACHE_DISCONNECTED, that places IS_ROOT dentries on the s_anon list > and that is usually expected to not find an alias. Sounds good. > I suspect the code would be much clearer if we were to do a mass > s/DCACHE_DISCONNECTED/DCACHE_CONNECTING/ to make it clear that the > flag is not intended to cover the general case of when dentries are > floating around without parents. I'm all for it. bfields@pepper:linux-2.6$ git grep DCACHE_DISCONNECTED|wc -l 24 So it's not so terrible. All but a few are in dcache.c and expfs.c. > I am in the final stages of putting together some patches so that > filesystems don't need to like to the vfs to preserve vfs invariants > about mountpoints. In particular I am implemeting automatic detaching > of mountpionts on unlink and d_invalidate. Once that is done and > everyone is dropping directory dentries instead of sticking to the > silly 2.2 era logic that present resides in d_invalidate some of these > other dcache uses should become a little less mysterious. OK. --b. -- 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
