On Fri, Nov 07, 2014 at 01:51:46PM -0800, Darrick J. Wong wrote:
> Dynamically grow the block zeroing buffer to a maximum of 4MB, and
> allow callers to provide their own zeroed buffer.
>
> +
> + /* If the user gave us a buffer, write that out */
> + if (block_buf) {
> + retval = io_channel_write_blk64(fs->io, blk, num, block_buf);
> + if (retval) {
> + if (ret_count)
> + *ret_count = num;
> + if (ret_blk)
> + *ret_blk = blk;
> + }
> +
> + return retval;
> + }
I've looked through the whole patch series,and there's only a single
caller of the new ext2fs_zero_blocks3 function --- and the caller is
going to be giving us a pre-zero'ed buffer, it might as well call
io_channel_write_blk64() directly instead of the new
ext2fs_zero_block3(). This is what we do in 1.42.x, and it makes a
lot more sense than changing the code to call ext2fs_zero_blocks3(),
and requiring it to depend on the caller having zero'ed the block
buffer, and then adding absolutely no value other than calling
i_channel_zeroout(), having it return UNIMPLEMENTED because it makes
no sense to use BLKZEROOUT, and then falling back to
io_channel_write_blk64().
So what I think makes sense is to drop the new ext2fs_zero_blocks3()
function, and to revert the change in ext2fs_alloc_block2() so that it
calls io_channel_write_blk64() instead of ext2fs_zero_block2().
I'll take care of making this change in the patch.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
