Andreas Dilger <adilger@xxxxxxxxx> wrote: > - I'd prefer calling these "file.generation" and "file.version". > I don't think there is value in the "i_" prefix adds anything, > and it seems more like an internal detail to me That's reasonable. > - why not expose the ".version" field for regular files? It seems > that all of them are applicable for all file types. Because Ext4 doesn't support it for anything other than directories. > - it would be good to not introduce a new xattr namespace, since > tools like tar (even the RHEL-patched one) will not backup and > restore these namespaces. Using "trusted." would allow them to > be backed up and restored using existing xattr-patched GNU tar > by root, but wouldn't allow them to be modified by regular users. > I think this is important for proper backup/restore of a filesystem, > but can have correctness implications and shouldn't be accessible > to regular users. Does backing them up make sense, though? They are filesystem structural attributes. Can you restore the inode number, for example? If not, then you can't restore i_generation either. Restoring i_version might make sense, but what if it winds i_version backwards whilst maintaining i_ino and i_generation, that means there'll be a time in the future where the three values are once again what might have been already published - and may already be in someone's persistent cache. > > file.crtime=0x53ba244c000000000000000000000000 > > Is this a binary (host-endian) struct timespec? Yes. That might not be the best representation, however. It could also be, say "<decimal-secs>.<decimal-nsecs>", eg: "1234.000000567". > > file.i_generation=0x0000000000000000 > > This seems odd, i_generation should never be zero, AFAIK. That might be because it's the root directory, and so cannot be replaced. David -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
