From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amir Goldstein Subject: Re: [PATCH v2 04/11] ovl: store file handle of lower inode on copy up Date: Wed, 26 Apr 2017 12:27:17 +0300 Message-ID: References: <1493025256-27188-1-git-send-email-amir73il@gmail.com> <1493025256-27188-5-git-send-email-amir73il@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-oi0-f68.google.com ([209.85.218.68]:33592 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2997120AbdDZJ1T (ORCPT ); Wed, 26 Apr 2017 05:27:19 -0400 In-Reply-To: Sender: linux-unionfs-owner@vger.kernel.org List-Id: linux-unionfs@vger.kernel.org To: Miklos Szeredi Cc: Vivek Goyal , Al Viro , "linux-unionfs@vger.kernel.org" , linux-fsdevel On Wed, Apr 26, 2017 at 12:21 PM, Miklos Szeredi wrote: > On Wed, Apr 26, 2017 at 7:47 AM, Amir Goldstein wrote: >> On Tue, Apr 25, 2017 at 5:53 PM, Miklos Szeredi wrote: >>> On Mon, Apr 24, 2017 at 11:14 AM, Amir Goldstein wrote: >>>> Sometimes it is interesting to know if an upper file is pure >>>> upper or a copy up target, and if it is a copy up target, it >>>> may be interesting to find the copy up origin. >>>> >>>> This will be used to preserve lower inode numbers across copy up. >>>> >>>> Store the lower inode file handle in upper inode xattr overlay.fh >>>> on copy up to use it later for these cases. >>>> >>>> On failure to encode lower file handle, store an invalid 'null' >>>> handle, so we can always use the overlay.fh xattr to distignuish >>>> between a copy up and a pure upper inode. >>>> >>>> If lower fs does not support NFS export ops or if not all lower >>>> layers are on the same fs, don't try to encode a lower file handle >>>> and use the 'null' handle instead. >>> >>> Decoding fh on wrong fs is going to result in "interesting" >>> posibilities, so I think we should be storing some kind of identifier >>> about the layer from the very start. >>> >>> The trivial way to do that would be to encode the filesystem's UUID >>> into the stored fh. Problem seems to be that only ext4 is setting >>> sb->s_uuid. Probably not too hard to fix the others. >>> >> >> xfs supports sb->s_export_op->get_uuid() (and seems to be the only >> fs that supports exportfs block ops). It may be more appropriate >> for our use case (universal unique file handle) to use this API >> and add support for it in other fs. >> We can also use the existence of sb->s_export_op->get_uuid >> as a promise for a persistent/exportable sb uuid instead of assuming >> that sb->s_uuid has such properties. > > Right, if ->get_uuid() could be made to work on all exportable fs, > than that would be good. > > The "offset" argument worries me a little. And we'd need to get rid > of the printk in the xfs code (or move it to pnfsd, which is where it > belongs). > The offset argument is discard-able, it gives you more information than we need. Another problem is that ->get_uuid for xfs is compiled out by default without CONFIG_PNFSD, although this could be changed. Anyway, I have a very simple patch for xfs to set sb->s_uuid. btrfs has several uuid's (i.e. subvolumes) on the same sb struct IIUC, so need to see how to handle this. Amir.