Re: [Ocfs2-devel] [RFC] The reflink(2) system call v4.

[Jamie Lokier <jamie@shareable.org>]

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