Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable

J. Bruce Fields
2017-01-13T20:02:55Z

On Fri, Jan 13, 2017 at 07:57:06PM +0000, Al Viro wrote:
> 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:

Thanks for the summary.

> 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?

Dunno, I thought I tried to remove it once some time ago, but my memory
may be wrong. It seems like nothing more than a trap for the unwary.

--b.