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. > When decoding, trivial to check in the samefs case, but we'd need a > table for the uuid->layer lookup for the non-samefs case. But that can > wait, I'd be content with just having the infrastructure there and > just using it to verify the handle for now. > Sounds good. I'll do the same_lower_sb implementation for v3. Thanks, Amir.
