Jonathan Corbet wrote: > One tiny little thing that crossed my mind as I was looking at this... > > > - REFLINK_ATTR_NONE is 0 and REFLINK_ATTR_ALL is ~0. > > That, I think, could lead to unexpected results if different flags > (perhaps controlling different aspects of behavior altogether) are > added in the future. Might it make more sense for REFLINK_ATTR_ALL to > be something like 0xffff, with the current implementation insisting > that all other bits are zero? That would leave room for expansion of > the set of things covered by the "preserve all" semantics while, > simultaneously, allowing the addition of different types of flags > entirely. I think it's far better if REFLINK_ATTR_ALL is simply it's own 1-bit flag, meaning exactly what you think it means: In the kernel, it sets all the attribute flags. It's possible to choose a bit-mask now, but there's no particular reason that 16 bits is the right size, and it's ugly if it turns out you need a hack for a backward-compatible 17th attribute sometime. (It can be done, it's just ugly). (I'd also add REFLINK_ATTR_ATOMIC, because you might want the attributes copied but don't care about atomicity, and some filesystems might be able to one without the other. I'm thinking of SMB/CIFS here.) By the way, there is work going on towards a "selective stat()" call, which takes a set of bits for which attributes are to be returned. Is it worth converging on some common flags to select attributes? -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
