All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Fabian Frederick <fabf@skynet.be>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, neilb@suse.com
Subject: Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable
Date: Fri, 13 Jan 2017 19:57:06 +0000	[thread overview]
Message-ID: <20170113195706.GO1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20170113190357.GI24709@fieldses.org>

On Fri, Jan 13, 2017 at 02:03:57PM -0500, J. Bruce Fields wrote:
> On Fri, Jan 13, 2017 at 10:52:54AM -0800, Christoph Hellwig wrote:
> > On Fri, Jan 13, 2017 at 12:39:12PM -0500, J. Bruce Fields wrote:
> > > If we're going to reject patches that don't implement get_parent (and I
> > > think we should), then we should replace "optional but strongly
> > > recommended" there by just "mandatory".  Any objections?
> > 
> > In theory yes - we'll just need an exception (or dummy implementation)
> > for in-memory file systems like tmpfs.
> 
> Hm, so does get_parent just never get called for tmpfs because the
> parent's always there already?

	As the matter of fact, tmpfs *does* have a dummy ->get_parent().
FWIW, the situation right now looks so:
	1) most of the local filesystems: get_parent/fh_to_dentry/fh_to_parent.
efs, exofs, ext2, ext4, f2fs, fat, jffs2, jfs, ntfs, squashfs, udf, ufs are
that way.
	2) ditto, but with non-default ->encode_fh() (that's basically those
who need more than 32-bit inumber to get to an inode).  Often enough those
have non-default ->get_name() as well - default one relies upon in-core
->i_ino matching whatever getdents(2) puts into d_ino; besides, there might
be a faster way to search.  Ones without ->get_name(): fat_nostale, fuse,
isofs, nilfs2, ocfs2, reiserfs.  Ones with: lustre, btrfs, ceph, gfs2.
	3) shmem - essentially as (2), but there ->get_parent() is
a dummy and so's ->fh_to_parent(), the latter represented by NULL rather
than as an explicit stub.
	4) orangefs - no ->fh_to_parent, no ->get_parent.  Not sure if
orangefs has a way to get khandle of parent by that of directory (i.e.
if it can open a disconnected directory by khandle and then obtain
a khandle of parent from it).  They do include khandle of directory into
on-the-wire fhandle, but never actually use that part.  Might be blind
copying of what other fs are doing, might be something they plan to do
but hadn't gotten around to.  If it's the latter, that's yet another class
2 (and it'll definitely need a ->get_name() then).
	5) befs - ->fh_to_dentry/->fh_to_parent, no ->get_parent.  IIRC,
they simply don't have a way to find the parent by directory.
	6) cifs - stub ->get_parent(), NULL everything else, impossible
to use and what the hell is fs/cifs/export.c is doing in the tree, anyway?

  reply	other threads:[~2017-01-13 19:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-03 21:30 [PATCH 3/6 linux-next] fs/affs: make affs exportable Fabian Frederick
2017-01-03 22:29 ` Al Viro
2017-01-04  5:53   ` Fabian Frederick
2017-01-13 17:39     ` J. Bruce Fields
2017-01-13 18:52       ` Christoph Hellwig
2017-01-13 19:03         ` J. Bruce Fields
2017-01-13 19:57           ` Al Viro [this message]
2017-01-13 20:02             ` J. Bruce Fields
2017-01-04 17:51   ` Fabian Frederick

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=20170113195706.GO1555@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=bfields@fieldses.org \
    --cc=fabf@skynet.be \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.