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

[Mingming Cao <cmm@us.ibm.com>]

On Fri, 2005-04-29 at 13:57 -0700, Andrew Morton wrote:
> Mingming Cao <cmm@us.ibm.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/