On Thu, 2011-09-08 at 10:42 -0700, Linus Torvalds wrote: > On Thu, Sep 8, 2011 at 6:38 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > Yes, 2.6.38 and later kernels do trigger on stat(2) but not on lstat(2). > > > > My question is this: does this behavior improve anything compared to > > kernels before 2.6.38? Because I don't see that it does, in fact it's > > just causing regressions. > > > > 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? The problem that is seen is everything in a directory being mounted upon listing the directory. This isn't really a problem for small automount maps but maps with more than a few dozen entries start becoming problematic and a few hundred entries or more (quite common in many environments) is an obvious nightmare. Clearly this is a problem that I have introduced by the idea of the "browse" option of autofs, whereby the potential automount points of an indirect automount are visible within the automount managed directory but it also applies to NFS crossing mount points (since those mount point directories must also pre-exist). Note that this isn't as problem if the "browse" option isn't used since we just se an empty directory and specific access to a path causes only those mounts to occur. But Solaris has been able to do this for years now so it is expected by the user community. > > I'm inclined to apply the patch as a regression fix, but I'll let this > thread try to convince me for another day.. I have to agree, although it would be good to get some input from other subsystem maintainers. Ian -- 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
