Messages in this thread | | | Subject | Re: [Ext2-devel] [RFC] Adding multiple block allocation | From | Mingming Cao <> | Date | Fri, 29 Apr 2005 14:12:19 -0700 |
| |
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/
| |