On Mon, Dec 05, 2016 at 08:39:15PM -0500, Oleg Drokin wrote: > > Basically it all started with mountpoints randomly getting unmounted during > > testing that I could not quite explain (see my quoted message at the end). > > > > Now I finally caught the culprit and it's lookup_dcache calling d_invalidate > > that in turn detaches all mountpoints on the entire subtree like this: Yes, it does. > > While I imagine the original idea was "cannot revalidate? Nuke the whole > > tree from orbit", cases for "Why cannot we revalidate" were not considered. What would you do instead? > > So this brings up the question: > > Is revalidate really required to go to great lengths to avoid returning 0 > > unless the underlying name has really-really changed? My reading > > of documentation does not seem to match this as the whole LOOKUP_REVAL logic > > is then redundant more or less? LOOKUP_REVAL is about avoiding false _postives_ on revalidation - i.e. if you have several layers of actually stale entries in dcache and notice only when you try to do lookup in the last one, with server telling you to fuck off, your only hope is to apply full-strength revalidation from the very beginning. Again, the problem it tries to avoid is over-optimistic fs assuming that directories are valid without asking the server. > > Or is totally nuking the whole underlying tree a little bit over the top and > > could be replaced with something less drastic, after all following re-lookup > > could restore the dentries, but unmounts are not really reversible. Like what? Seriously, what would you do in such situation? Leave the damn thing unreachable (and thus impossible to unmount)? Suppose the /mnt/foo really had been removed (along with everything under it) on the server. You had something mounted on /mnt/foo/bar/baz; what should the kernel do? -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
