Messages in this thread | | | Date | Sat, 3 Sep 2022 18:52:16 +0100 | From | Al Viro <> | Subject | Re: [PATCH 01/10] VFS: support parallel updates in the one directory. |
| |
On Sat, Sep 03, 2022 at 03:12:26AM +0100, Al Viro wrote:
> Very much so. You are starting to invent new rules for ->lookup() that > just never had been there, basing on nothing better than a couple of > examples. They are nowhere near everything there is.
A few examples besides NFS and autofs:
ext4, f2fs and xfs might bloody well return NULL without hashing - happens on negative lookups with 'casefolding' crap.
kernfs - treatment of inactive nodes.
afs_dynroot_lookup() treatment of @cell... names.
afs_lookup() treatment of @sys... names.
There might very well be more - both merged into mainline and in development trees of various filesystems (including devel branches of in-tree ones - I'm not talking about out-of-tree projects).
Note, BTW, that with the current rules it's perfectly possible to have this kind of fun: a name that resolves to different files for different processes unlink(2) is allowed and results depend upon the calling process
All it takes is ->lookup() deliberately *NOT* hashing the sucker and ->unlink() acting according to dentry it has gotten from the caller. unlink(2) from different callers are serialized and none of that stuff is ever going to be hashed. d_alloc_parallel() might pick an in-lookup dentry from another caller of e.g. stat(2), but it will wait for in-lookup state ending, notice that the sucker is not hashed, drop it and retry. Suboptimal, but it works.
Nothing in the mainline currently does that. Nothing that I know of, that is. Sure, it could be made work with the changes you seem to imply (if I'm not misreading you) - all it takes is lookup calling d_lookup_done() on its argument before returning NULL. But that's subtle, non-obvious and not documented anywhere...
Another interesting question is the rules for unhashing dentries. What is needed for somebody to do temporary unhash, followed by rehashing?
| |