From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fieldses.org ([173.255.197.46]:34070 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750805AbdAMUCv (ORCPT ); Fri, 13 Jan 2017 15:02:51 -0500 Date: Fri, 13 Jan 2017 15:02:06 -0500 From: "J. Bruce Fields" To: Al Viro Cc: Christoph Hellwig , Fabian Frederick , Andrew Morton , linux-kernel@vger.kernel.org, Jan Kara , linux-fsdevel@vger.kernel.org, neilb@suse.com Subject: Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable Message-ID: <20170113200206.GA28491@fieldses.org> References: <1483479039-5255-1-git-send-email-fabf@skynet.be> <20170103222906.GC1555@ZenIV.linux.org.uk> <736635494.1055379.1483509211858.open-xchange@webmail.nmp.proximus.be> <20170113173912.GH24709@fieldses.org> <20170113185254.GA6092@infradead.org> <20170113190357.GI24709@fieldses.org> <20170113195706.GO1555@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170113195706.GO1555@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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.