On Mon, 2009-08-17 at 20:18 -0400, Theodore Tso wrote:
> Here's my suggest rewrite of the patch description:
>
> ext4: Direct IO for holes and fallocate: unwritten extents spt for DIO
>
> From: Mingming <cmm@xxxxxxxxxx>
>
> When writing into an unitialized extent via direct I/O, and the direct
> I/O doesn't exactly cover the unitialized extent, split the extent
> into uninitialized and initialized extents before submitting the I/O.
~~~~~~~~~~~~
would it better to replace this as to-be-initialized extents? Before
submmit the I/O, the extents are splitted but all remains uninitialized.
The written part is converted to initialized at the time I/O is
complete.
> The reason for doing this is to avoid needing to deal with an ENOSPC
> error in the end_io callback that gets used for direct I/O.
>
> Singed-Off-By: Mingming Cao <cmm@xxxxxxxxxx>
> Signed-off-by: "Theodore Ts'o" <tytso@xxxxxxx>
>
> ------------------
>
>
> As mentioned in my comments for the previous patch,
> ext4_convert_unwritten_extents() needs to be defined in the previous
> patch. This may requiring dragging in substantial portions of this
> patch.
>
> The other observation is there seems to be quite a bit of overlap
> between ext4_split_unwritten_extents() and
> ext4_ext_convert_to_initialized(). Is there some way we can do some
> code factorization?
>
I thought about factor the code before... that would require passing a
flag and avoid the convertion(as for DIO case we only do split) and zero
out( DIO does less agreesive zero out than buffered IO). It makes code
actually hard to read. I will give it a try to see if we could reuse the
code while still make the code easy to understand.
Thanks,
Mingming
> - 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
