Re: [PATCH v2 04/11] ovl: store file handle of lower inode on copy up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 26, 2017 at 12:21 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Wed, Apr 26, 2017 at 7:47 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>> On Tue, Apr 25, 2017 at 5:53 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>>> On Mon, Apr 24, 2017 at 11:14 AM, Amir Goldstein <amir73il@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux