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
