Eryu Guan <guaneryu@xxxxxxxxx> writes:
> What we should really do is to disable block allocation for writes that
> could result in filling holes inside i_size.
>
> Reviewed-by: Jan Kara <jack@xxxxxxx>
> Signed-off-by: Eryu Guan <guaneryu@xxxxxxxxx>
This looks good to me, Eryu, and it passes the aio/dio test cases in
xfstests and libaio. Thanks a lot!
Al, can you take this through your tree?
Reviewed-by: Jeff Moyer <jmoyer@xxxxxxxxxx>
> ---
>
> v3:
> - Kill unnecessary cleanup patch
> - Update comments a bit accordingly
>
> v2:
> - Fix the case Jeff pointed out as well
> - Update commit log
>
> fs/direct-io.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/fs/direct-io.c b/fs/direct-io.c
> index 4720377..62921ce 100644
> --- a/fs/direct-io.c
> +++ b/fs/direct-io.c
> @@ -627,11 +627,11 @@ static int get_more_blocks(struct dio *dio, struct dio_submit *sdio,
> map_bh->b_size = fs_count << i_blkbits;
>
> /*
> - * For writes inside i_size on a DIO_SKIP_HOLES filesystem we
> - * forbid block creations: only overwrites are permitted.
> - * We will return early to the caller once we see an
> - * unmapped buffer head returned, and the caller will fall
> - * back to buffered I/O.
> + * For writes that could fill holes inside i_size on a
> + * DIO_SKIP_HOLES filesystem we forbid block creations: only
> + * overwrites are permitted. We will return early to the caller
> + * once we see an unmapped buffer head returned, and the caller
> + * will fall back to buffered I/O.
> *
> * Otherwise the decision is left to the get_blocks method,
> * which may decide to handle it or also return an unmapped
> @@ -639,8 +639,8 @@ static int get_more_blocks(struct dio *dio, struct dio_submit *sdio,
> */
> create = dio->rw & WRITE;
> if (dio->flags & DIO_SKIP_HOLES) {
> - if (sdio->block_in_file < (i_size_read(dio->inode) >>
> - sdio->blkbits))
> + if (fs_startblk <= ((i_size_read(dio->inode) - 1) >>
> + i_blkbits))
> create = 0;
> }
--
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
