From: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Andreas Dilger <aedilger@gmail.com>,
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: Mon, 09 Jan 2012 14:55:04 +0100 [thread overview]
Message-ID: <4F0AF1B8.8030903@itwm.fraunhofer.de> (raw)
In-Reply-To: <20111230075714.GV23916@ZenIV.linux.org.uk>
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
next prev parent reply other threads:[~2012-01-09 13:55 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
2012-01-09 13:55 ` Bernd Schubert [this message]
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=4F0AF1B8.8030903@itwm.fraunhofer.de \
--to=bernd.schubert@itwm.fraunhofer.de \
--cc=aedilger@gmail.com \
--cc=dan.magenheimer@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sage@newdream.net \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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).