[Cluster-devel] [PATCH v2 2/3] GFS2: Implement iomap for block_map

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On 31/10/16 20:07, Dave Chinner wrote:
> On Sat, Oct 29, 2016 at 10:24:45AM +0100, Steven Whitehouse wrote:
>> On 28/10/16 20:29, Bob Peterson wrote:
>>> +	if (create)
>>> +		flags |= IOMAP_WRITE;
>> Hmm, I wonder why IOMAP_WRITE and IOMAP_ZERO are separate flags from
>> the iomap.flags field... Christoph, was there a specific reason for
>> that?
> They are different actions. IOMAP_WRITE requires allocation over
> holes and conversion of unwritten extents to allow writing of
> user data into the range. IOMAP_ZERO is for zeroing a range of a
> file via iomap_zero_range() and it does not require allocation - it
> skips holes and unwritten regions as they are already guaranteed to
> contain zeros.
>
> One *could* allocate blocks with IOMAP_ZERO if desired (i.e.
> implement IOMAP_ZERO as though it implied IOMAP_WRITE) and
> iomap_zero_range_actor() will zero the allocated regions
> appropriately, but it's not necessary to do if it is already known
> what ranges of the file contain zeros...
>
> Cheers,
>
> Dave.
That wasn't quite what I was getting at... we have two sets of flags. 
IOMAP_ZERO, IOMAP_WRITE and IOMAP_REPORT form one set that are passed as 
an argument to ->iomap_begin() and ->iomap_end() whereas we also have 
IOMAP_F_* which are set in the iomap.flags field. I guess perhaps the 
former is intended as the input flags to the functions, where as the 
latter are output flags from ->iomap_begin()? In that case I would 
expect that ->iomap_end() would view the iomap.flags as read only.

Just trying to get my head around the intention here and then we can 
figure out the right thing to do gfs2-wise based on that,

Steve.