Re: [PATCH] VFS: Suppress automount on [l]stat, [l]getxattr, etc.

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, Sep 25, 2011 at 10:11 PM, Ian Kent <raven@themaw.net> wrote:
> On Sat, 2011-09-24 at 08:56 -0700, Linus Torvalds wrote:
>>
>>    Now, if the auto-mounting actually have a whole different kind of
>> file type for an unmounted entry (not necessarily S_IFLNK - I could
>> well imagine a new implementation just saying "we'll return the new
>> S_IFAUTO marker"), then using lstat/stat the same way as for symlinks
>> would make sense. And maybe that would have been a good thing: then
>> "ls" could show those things nicely as "unmounted automount points".
>
> And that's the heart of it.
>
> We added VFS automounting but somehow we managed to retain the "second
> class VFS citizen" nature historic with automouning.

Well, realistically, we had to.

And we *still* have to.

There is absolutely no way in hell that we will teach user space about
a new "unmounted automount" inode type.

The is a metric sh*tload of programs that know about and use S_ISDIR()
and brethren. We realistically can't just break them because it would
be nice. The annoyance factor is too high, but more importantly, the
*advantage* is too low.

automounts just simply aren't important enough to warrant it. Most
people aren't aware of them, even if they are on a system where they
are in use. And that's relatively rare to begin with.

So I put it out as a "if this was a new design, and we didn't have any
existing code issues, it *should* possibly have been done that way".
But it was purely theoretical, because whil eI think it would be a
"clean solution", I seriously don't think it's a *realistic* solution
these days any more.

Sure, we could do it with a mount flag and let people try to migrate
if they wanted to, but realistically, simplicity is a bigger win than
"hey, give people the option to do it". Especially since there isn't
any real clamor from actual users for this - it's purely a theoretical
'wouldn't it have been nice if..' argument.

> OTOH, due to the fact we have such controversy, maybe that's a case for
> doing this from the outset. Thoughts? Dare I say, can we reach agreement
> on it?

Seriously, I have seen absolutely *zero* arguments for just trying to
go with the "keep it simple, stupid" approach.

What are the downsides of just adding the one or two
LOOKUP_DIRECTORY/LOOKUP_OPEN flags?

Nobody has even *mentioned* any downsides. So I don't think this is
controversial, and I don't understand why you consider it
controversial.

                     Linus