On Tue, 2011-09-06 at 11:53 +0800, Ian Kent wrote: > On Mon, 2011-09-05 at 19:02 +0200, Miklos Szeredi wrote: > > David Howells <dhowells@xxxxxxxxxx> writes: > > > > > Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > >> After 2.6.38, with the introduction of the ->d_automount() > > >> infrastructure, stat(2) and others would start triggering automount > > >> while lstat(2), etc. still would not. This is a regression and a > > >> userspace ABI change. > > > > > > It doesn't necessarily mean it's wrong. The main class of program that needs > > > to be prevented from automounting are things that do bulk stat'ing (e.g. ls) - > > > and they should probably be doing lstat() anyway. > > > > Yeah, some of those uses are probably minor bugs in userspace, but there are > > probably many of them (Leonardo reported that for example Nautilus also > > triggers all child automounts in a directory). So I don't think it's OK to > > just change the behavior here. > > Yes, Leonard has been a big help with his recent efforts, thanks > Leonard. > > > > > If automounting on lstat(2) is the correct behavior (is it? why?) then at > > least it should be enabled by a global switch or mount option, IMO. > > Ideally we wouldn't need to take special precautions for these > operations at all but we can't, especially for GUI environments that > constantly scan file systems on mount/umount activity. > > Historically for autofs, neither stat(2) or lstat(2) would trigger a > mount. With the current implementation stat(2) now does but lstat(2) > doesn't which is a step in the right direction IMHO. So, I recommend we > continue to encourage user space to make the needed changes so we > continue to move in the right direction, and yes, I acknowledge it is a > pain but it'll never get done otherwise. > > And, yes, other subsystems that need to automount also have the same > problems as autofs now so we do need to take precautions, but that was > already the case before the current implementation. > > Hopefully, in time, user space will adopt the use of fcntl(2) and > AT_NO_AUTOMOUNT and we will be able to fix this once and for all, as > this was David's intent in introducing it. Not quite sure how we will go > about promoting that adoption or how much pain that will mean for user > space though. Actually, maybe that's not entirely sensible either, now that I think about it. Isn't it so that if we have one process that shouldn't trigger mounts and sets the flag, other processes that possibly should won't either ... mmm ... I'll need to check that. 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
