lkml.org 
[lkml]   [2007]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Direct IO for fat
    > On Fri 09-02-07 01:40:31, OGAWA Hirofumi wrote:
    > > Jan Kara <jack@suse.cz> writes:
    > >
    > > >> FAT has to fill the hole completely, but DIO doesn't seems to do.
    > > >>
    > > >> e.g.
    > > >> fd = open("file", O_WRONLY | O_CREAT | O_TRUNC);
    > > >> write(fd, buf, 512);
    > > >> lseek(fd, 10000, SEEK_SET);
    > > >> write(fd, buf, 512);
    > > >>
    > > >> We need to allocate the blocks on 512 ~ 10000, and fill it with zero.
    > > >> However, I think DIO doesn't fill it. If I'm missing something, please
    > > >> let me know, I'll kill that check.
    > > > I know. DIO doesn't do it. But the point is that if blockdev_direct_IO
    > > > finds out it should allocate new blocks, it exits without allocating them.
    > > > Then in __generic_file_aio_write_nolock() if we find out that we did not
    > > > write everything in generic_file_direct_write(), we just call
    > > > generic_file_buffered_write() to write the unwritten part.
    > > > Hence, in case you describe above, the second write() finds out that
    > > > block is not allocated and eventually everything falls back to calling
    > > > generic_file_buffered_write() which calls prepare_write() and everything is
    > > > happy.
    > >
    > > I see. But sorry, I can't see where is preventing it... Finally, I
    > > think we do the following on second write(2).
    > >
    > > This is write, so create == 1, and ->lock_type == DIO_LOCKING,
    > > and dio->block_in_file > ->i_size, so DIO callback fat_get_block() with
    > > create == 1.
    > I think you misread the code - see below.
    >
    > > Then fat_get_block() seems to allocate block without fill hole,
    > > because it can't know caller is prepre_write or not...
    > > Well, anyway I'll test it on weekend. Thanks.
    > >
    > > -> blockdev_direct_IO()
    > > -> direct_io_worker()
    > > -> do_direct_IO()
    > > -> get_more_blocks()
    > >
    > > create = dio->rw & WRITE;
    > Here, create == 1.
    >
    > > if (dio->lock_type == DIO_LOCKING) {
    > > if (dio->block_in_file < (i_size_read(dio->inode) >>
    > > dio->blkbits))
    > > create = 0;
    > But here create was reset back to 0 - exactly because
    > dio->block_in_file > i_size...
    Obviously, I'm blind and you're right ;) This test is not satisfied
    and so create == 1.
    But still it would seem better to me to return 0 from fat_direct_IO()
    instead of EINVAL so that write falls back to a buffered one, instead
    returning the error...

    Honza
    --
    Jan Kara <jack@suse.cz>
    SuSE CR Labs
    -
    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/

    \
     
     \ /
      Last update: 2007-02-08 19:43    [W:2.332 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site