Re: [Ext2-devel] [RFC] Adding multiple block allocation

From: Mingming Cao
Date: Fri Apr 29 2005 - 16:24:53 EST


On Fri, 2005-04-29 at 13:57 -0700, Andrew Morton wrote:
> Mingming Cao <cmm@xxxxxxxxxx> wrote:
> >
> > If we do direct write(block allocation) to a hole, I found that the
> > "create" flag passed to ext3_direct_io_get_blocks() is 0 if we are
> > trying to _write_ to a file hole. Is this expected?
>
> Nope. The code in get_more_blocks() is pretty explicit.
>
> > But if it try to allocating blocks in the hole (with direct IO), blocks
> > are allocated one by one. I am looking at it right now.
> >
>
> Please see the comment over get_more_blocks().
>

I went to look at get_more_blocks, the create flag is cleared if the
file offset is less than the i_size. (see code below).

static int get_more_blocks(struct dio *dio)
{
..........
.........
create = dio->rw == WRITE;
if (dio->lock_type == DIO_LOCKING) {
if (dio->block_in_file < (i_size_read(dio->inode) >>
dio->blkbits))
create = 0;
} else if (dio->lock_type == DIO_NO_LOCKING) {
create = 0;

ret = (*dio->get_blocks)(dio->inode, fs_startblk, fs_count,
map_bh, create);

}

When it is trying to direct writing to a hole, the create flag is
cleared so that the underlying filesystem get_blocks() function will
only do a block look up(look up will be failed and no block allocation).

do_direct_IO -> get_more_blocks -> ext3_direct_io_get_blocks. In
get_more_blocks(), do_direct_IO() handles the write to hole situation
by simply return an error of ENOTBLK. In direct_io_worker() it detects
this error then just simply return the size of written byte to 0. The
real write is handled by the buffered I/O. In
__generic_file_aio_write_nolock(), generic_file_buffered_write() will be
called if written by generic_file_direct_write() is 0.

Could you confirm my observation above? Hope I understand this right:
right now direct io write to a hole is actually handled by buffered IO.
If so, there must be some valid reason that I could not see now.


Thanks,
Mingming

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/