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). Amir.
