From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [Ocfs2-devel] [RFC] The reflink(2) system call v4. Date: Tue, 19 May 2009 21:15:48 +0100 Message-ID: <20090519201548.GA4378@shareable.org> References: <20090511204011.GB30293@mail.oracle.com> <4A0B96C6.40702@mit.edu> <1242324765.21772.95.camel@localhost.localdomain> <20090514220029.GB30410@mail.oracle.com> <1242388905.29973.17.camel@localhost.localdomain> <20090515152212.GA31454@mail.oracle.com> <1242402925.29973.163.camel@localhost.localdomain> <20090515164209.GD31454@mail.oracle.com> <20090515205335.GB25787@mail.oracle.com> <20090519133356.1c90e4ed@bike.lwn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org To: Jonathan Corbet Return-path: Content-Disposition: inline In-Reply-To: <20090519133356.1c90e4ed@bike.lwn.net> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.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