From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>, Ian Kent <raven@themaw.net>,
David Howells <dhowells@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Leonardo Chiquitto <leonardo.lists@gmail.com>,
autofs@linux.kernel.org
Subject: Re: [PATCH] vfs: automount should ignore LOOKUP_FOLLOW
Date: Thu, 8 Sep 2011 20:50:43 +0100 [thread overview]
Message-ID: <20110908195043.GV2203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFy3VN2Y-oadFUMdCaBVQtPT9Ae3fDQCw5vHfA6UvH8GiA@mail.gmail.com>
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...
next prev parent reply other threads:[~2011-09-08 19:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-05 16:06 [PATCH] vfs: automount should ignore LOOKUP_FOLLOW Miklos Szeredi
2011-09-05 16:37 ` David Howells
2011-09-05 17:02 ` Miklos Szeredi
2011-09-06 3:53 ` Ian Kent
2011-09-06 4:03 ` Ian Kent
2011-09-06 8:09 ` Miklos Szeredi
2011-09-06 14:38 ` Ian Kent
2011-09-06 15:39 ` Miklos Szeredi
2011-09-08 12:36 ` Ian Kent
2011-09-08 13:38 ` Miklos Szeredi
2011-09-08 17:42 ` Linus Torvalds
2011-09-08 19:50 ` Al Viro [this message]
2011-09-08 20:19 ` Linus Torvalds
2011-09-08 21:54 ` Al Viro
2011-09-09 3:37 ` Ian Kent
2011-09-09 3:33 ` Ian Kent
2011-09-09 3:18 ` Ian Kent
2011-09-22 12:29 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110908195043.GV2203@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=autofs@linux.kernel.org \
--cc=dhowells@redhat.com \
--cc=leonardo.lists@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=raven@themaw.net \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.