On Thu, Sep 08, 2011 at 10:42:28AM -0700, Linus Torvalds wrote: > > You say it's a step in the right direction but I don't see why. ?Either > > we want stat *and* lstat to both be correct and trigger the automount or > > we are satisfied with the incorrect but well established practice of not > > triggering on (l)stat. > > > > The middle ground makes no sense IMO, there's nothing gained by the > > differentiated behavior based on LOOKUP_FOLLOW. > > > > Can you explain why it's better if stat() tiggers automounts and gives a > > correct result but lstat() doesn't? > > I have to say that this is a very cogent question. > > The one thing I've not seen in the thread yet is a description of the > failure. What does the regression look like? Just "very slow 'ls' with > some versions of 'ls'" or what? > > I'm inclined to apply the patch as a regression fix, but I'll let this > thread try to convince me for another day.. IIRC, that matches traditional SunOS behaviour and it actually does make sense; you want wildcard expansion and ls -l to be doable even when there's a stuck NFS server. IOW, non-triggering lstat(2) is a matter of usability... -- 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
