From: Al Viro <viro@ZenIV.linux.org.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: weigelt@metux.de, linux-kernel@vger.kernel.org
Subject: Re: VFS + path walktrough
Date: Mon, 5 May 2008 18:14:25 +0100 [thread overview]
Message-ID: <20080505171425.GO5882@ZenIV.linux.org.uk> (raw)
In-Reply-To: <E1Jt3nB-0006ZP-6S@pomaz-ex.szeredi.hu>
On Mon, May 05, 2008 at 06:43:57PM +0200, Miklos Szeredi wrote:
> One way this could be done cleanly, is to pass the rest of the path
> (as hint) to the filesystem in its lookup function. Most filesystems
> would just ignore it, but those which have the capabilities can use it
> to do the lookup in one go, and internally cache the result. The VFS
> doesn't need to know _anything_ about all this. If there are
> mountpoints, they are already cached, so ->lookup() wouldn't be called
> at all, only ->d_revalidate(), which is a different issue.
This is still wrong. We not just pass the pathname to filesystem (note
that you still need to deal with symlinks), but we make that filesystem
to populate dentry tree. Take a look at 9P walk - it does *not* give
you anything resembling stat, you just get qids of intermediates. Which
is bloody useful when you want to do intelligent revalidation (do local
cached walk, then issue a single protocol request that will both do
bulk revalidate *and* tell you where in the path you've got the first
invalid one - just compare qids with what you've got stored locally).
However, it's just about useless for cutting corners in cold-cache
lookup.
It _is_ a useful thing, no arguments about that. However, to use it
a sane way we need to massage the pathname resolution loop, taking
the "simple pass without symlinks or mountpoints" part into a new
helper, turning the current __link_path_walk() into a loop calling that
one and then folding it into callers. Would also allow to kill the
last remnants of recursion in symlink handling for normal fs case...
_Then_ we can do saner logics for revalidate, allowing it on such segments.
Which, BTW, would deal with -ESTALE in a saner way, rather than "repeat
full pathname resolution from the very beginning". And that's where
9P multi-step walk(5) would do very nicely, indeed.
And fuck the "hints" of all kinds, pardon the rudeness. We already have
more than enough of that crap and it already makes cleaning the logics
up bloody painful.
next prev parent reply other threads:[~2008-05-05 17:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-05 12:40 VFS + path walktrough Enrico Weigelt
2008-05-05 13:06 ` Enrico Weigelt
2008-05-05 13:13 ` Al Viro
2008-05-05 13:43 ` Enrico Weigelt
2008-05-05 15:35 ` Al Viro
2008-05-05 16:43 ` Miklos Szeredi
2008-05-05 17:03 ` Miklos Szeredi
2008-05-05 17:14 ` Al Viro [this message]
2008-05-05 17:33 ` Miklos Szeredi
2008-05-05 17:40 ` Al Viro
2008-05-05 18:03 ` Miklos Szeredi
2008-05-05 18:31 ` Miklos Szeredi
2008-05-05 20:16 ` Trond Myklebust
2008-05-05 20:35 ` Miklos Szeredi
2008-05-05 18:50 ` Enrico Weigelt
2008-05-05 18:23 ` Enrico Weigelt
2008-05-05 18:34 ` Al Viro
2008-05-05 19:02 ` Enrico Weigelt
2008-05-05 19:09 ` Al Viro
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=20080505171425.GO5882@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=weigelt@metux.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox