gfs2 IOMAP_ZERO confusion

gfs2 IOMAP_ZERO confusion

[Christoph Hellwig]

Hi Bob,

In "GFS2: Implement iomap for block_map" you seem to have misunderstood
the intention of the IOMAP_ZERO flag.  It it set if iomap_begin is
called for a zeroing operation, so that we don't allocate new blocks
for holes or unwritten extents.  It is not supposed to actually zero
the blocks.  Can you use some other way to communicate you internal
zeroing request?

Re: gfs2 IOMAP_ZERO confusion

[Bob Peterson]

----- Original Message -----
| Hi Bob,
| 
| In "GFS2: Implement iomap for block_map" you seem to have misunderstood
| the intention of the IOMAP_ZERO flag.  It it set if iomap_begin is
| called for a zeroing operation, so that we don't allocate new blocks
| for holes or unwritten extents.  It is not supposed to actually zero
| the blocks.  Can you use some other way to communicate you internal
| zeroing request?
| 
Hi Christoph,

I guess I misappropriated the flag because it seemed like a convenient
way to handle the buffer_zeronew() flag for our block_map function.

The problem is: since GFS2 is not extent-based, we have no good way to
mark groups of blocks as needing to be zeroed in the future, for purposes
like fallocate. I wish there was. There's definitely not enough bits in
our (2-bits-per-block) bitmap for that, although that would be nice.

So we can either add in a new iomap flag and do it when it's convenient,
or else handle the zeroing separately from functions that call iomap,
like in gfs2_block_map, fallocate, and so forth. Or perhaps something
that runs in the background like from a workqueue, etc.

What are your thoughts?

Regards,

Bob Peterson
Red Hat File Systems