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

[Steven Whitehouse]

Hi,

On 04/11/16 13:44, Christoph Hellwig wrote:
>>>> 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()
> They actually are the type of operation we perform, so maybe we should
> rename them to "op" or similar.
>
>> For GFS2 then we want to use the IOMAP_* flags as they are at the moment,
>> but for the function that maps back from iomap to gfs2_block_map() we'd need
>> to add a IOMAP_F_ZEROED or something like that from which to set the
>> BH_zeronew() flag, which is used as both a request and result flag for the
>> zeroing operation. That flag would very likely go away in due course when
>> the final iomap migration is done for GFS2, so would just be a temporary
>> thing in the mean time.
> That would be the existing IOMAP_F_NEW I guess?
Well maybe, maybe not... currently it differentiates between failure of 
allocation and failure of zeroing. Probably not really required except 
for lack of roll back on the allocation if the zeroing fails. Something 
to be fixed in due course I think.

>> I also wondered whether it would be possible to write a generic
>> implementation of SEEK_HOLE/SEEK_END for iomap supporting filesystems at the
>> VFS level. That would get GFS2 support for those two operations and be a
>> nice clean up too. I've added an item on our todo list for that, but it may
>> be a little while before we get around to it,
> Yes, that should be doable.  Would be great if you could look at it,
> otherwise I'll add it to my todo list.

Well, it is on our list, but we'll see who gets there first. We have 
quite a lot of other things that need doing too, so it is not top of the 
list right now,

Steve.