On Thu, Dec 11, 2014 at 09:37:56PM -0500, Theodore Ts'o wrote:
> 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.
Ok, thank you!
(Esp. since the power may or may not stay up out here in the West.)
--D
>
> - 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
--
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
