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 11:53 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> On Wed, Apr 26, 2017 at 12:39 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.
>>
>> One other question regarding this:  do we want  to store the handle of
>> the next file in the copy up chain or the handle of the original file?
>>
>> This patch seems to do the "next file" thing.  For directories,
>> obviously that's what we want, but for files...
>>
>
> What I found when working on this is that any file below to uppermost
> lower is of zero interest to us.
>
> So I defined 'stable inode' and we only need to lookup stable inode:
> Stable := uppermost lower (or upper if numlower == 0)
>
> For NFS export, Stable fh is unique enough, because
> when rotating upper layer or any change of layer stack configuration,
> NFS handles may become stale and this is fine.
>
> inode numbers are guarantied to remain constant and persistent
> as long as upper is not rotated.
> Rotating upper will change stable inode numbers and this is fine
> (regard it as cpio/tar of the filesystem).
>
> Hardlinks will be preserved as long as lower stack configuration
> doesn't change.
> When upper is rotated the copy up hardlink bunch will be broken
> from the non-copy-up hardlink bunch, which is quite a minor
> concern IMO (cpio/tar don't always preserve hardlinks).

Okay, makes sense.

Thanks,
Miklos
--
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