public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Allison Henderson <allison.henderson@oracle.com>,
	lsf-pc@lists.linux-foundation.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	Jeff Layton <jlayton@poochiereds.net>
Subject: Re: [LSF/MM TOPIC][LSF/MM ATTEND] Parent pointer future use cases
Date: Wed, 31 Jan 2018 10:30:25 -0500	[thread overview]
Message-ID: <20180131153025.GB15812@fieldses.org> (raw)
In-Reply-To: <CAOQ4uxhYrpY=POeATvh6GOJLNEwDrsQhvAKvyZzwcUQXGwLvDA@mail.gmail.com>

On Wed, Jan 31, 2018 at 09:34:52AM +0200, Amir Goldstein wrote:
> If filesystem were to provide a parents iterator interface, something like:
> get_acceptable_parent(child, acceptable, context)
> then xfs could iterate inode parents and call the nfsd_acceptable() callback.
> For filesystems that support get_acceptable_parent(), there is no need to
> encode a 'connectable' non unique file handle.
> 
> I am not sure how much of a problem the 'subtree_check' and non-unique
> file handle is for nfsd (CC nfsd folks for that), but I know I can make good use
> of that in overlayfs, as well as with an optimized get_name() implementation.

I hate subtree-checking and wish people would just stop trying to export
subtrees.

That said, anything that makes it less painful is probably good.

And, yes, the fact that filehandles can change when a file is renamed
across directories can be a problem for people using subtree checking.

--b.

  reply	other threads:[~2018-01-31 15:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-31  3:56 [LSF/MM TOPIC][LSF/MM ATTEND] Parent pointer future use cases Allison Henderson
2018-01-31  7:34 ` Amir Goldstein
2018-01-31 15:30   ` J. Bruce Fields [this message]
2018-01-31 16:09     ` Amir Goldstein
2018-01-31 16:40       ` J. Bruce Fields
2018-01-31 18:58   ` Darrick J. Wong
2018-01-31 19:52     ` Amir Goldstein
2018-01-31 18:46 ` Darrick J. Wong
2018-01-31 22:17   ` Allison Henderson
2018-01-31 23:57   ` Dave Chinner
2018-01-31 20:07 ` Andreas Dilger

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=20180131153025.GB15812@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=allison.henderson@oracle.com \
    --cc=amir73il@gmail.com \
    --cc=jlayton@poochiereds.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lsf-pc@lists.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