On 12/30/2011 08:57 AM, Al Viro wrote:
On Fri, Dec 30, 2011 at 01:14:16AM -0600, Andreas Dilger wrote:
On 2011-12-30, at 12:27 AM, Al Viro wrote:
One kinda-sorta solution (besides kicking cleancache out of tree)
would be to modify ->encode_fh() API - instead of dentry + connectable
pass it inode + NULL-or-parent-inode, with ->d_lock held by caller. And
demand it to be non-blocking, obviously... It would obviously break
ceph ->encode_fh(), since that sucker apparently wants the name of last
component anyway. OTOH, that's broken for reasons mentioned above.
OTTH, fhandle encoding is bloody close to user-visible ABI ;-/
Is it possible to always pass d_parent if this is available, rather than
only if @connectable is passed? For network filesystems re-exporting NFS
it is desirable to always be passed the parent directory.
Even without check_subtree on the export? Whatever the hell for?
Note that using the parent means broken rename() - fhandles will be
changed when file gets moved from one directory to another. It's
exactly what is asked for in case of check_subtree, but otherwise it's
an obvious misfeature. _And_ it costs extra locking and extra work
on decode_fh side...
I obviously looked only at the in-tree filesystems; out-of-tree code might
be doing very weird things, up to and including ROT13 of uuencoded UTF16
representation of pathname stored in fhandle. And yes, fh representation
is too close to being a part of ABI for comfort, but then it's an ABI
exported by out-of-tree code, so I'm not going to worry too much about
its stability...
"desirable for network filesystems" is too damn vague; could you give more
details?
FhGFS has the distributed metadata feature, where the parent directory
identifies the corresponding metadata server of a dentry.
I guess other parallel filesystems might take the same approach.
Cheers,
Bernd
--
Bernd Schubert
Fraunhofer ITWM
--
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
