From: Al Viro <viro@ZenIV.linux.org.uk>
To: Andreas Dilger <aedilger@gmail.com>
Cc: linux-fsdevel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Sage Weil <sage@newdream.net>,
Dan Magenheimer <dan.magenheimer@oracle.com>
Subject: Re: [RFC] ->encode_fh() and related breakage
Date: Fri, 30 Dec 2011 07:57:14 +0000 [thread overview]
Message-ID: <20111230075714.GV23916@ZenIV.linux.org.uk> (raw)
In-Reply-To: <AFED699D-AB38-4855-B00B-AE0C934287FE@dilger.ca>
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?
next prev parent reply other threads:[~2011-12-30 7:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-30 6:27 [RFC] ->encode_fh() and related breakage Al Viro
2011-12-30 7:14 ` Andreas Dilger
2011-12-30 7:57 ` Al Viro [this message]
2012-01-09 13:55 ` Bernd Schubert
2011-12-30 16:48 ` Dan Magenheimer
2012-01-03 11:31 ` Steven Whitehouse
2012-01-03 17:00 ` Sage Weil
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=20111230075714.GV23916@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=aedilger@gmail.com \
--cc=dan.magenheimer@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sage@newdream.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).