linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mingming Cao <cmm@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>, pbadari@us.ibm.com
Cc: suparna@in.ibm.com, sct@redhat.com, linux-kernel@vger.kernel.org,
	ext2-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] Adding multiple block allocation
Date: Fri, 29 Apr 2005 14:12:19 -0700	[thread overview]
Message-ID: <1114809139.10473.70.camel@localhost.localdomain> (raw)
In-Reply-To: <20050429135705.3f4831bd.akpm@osdl.org>

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



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

  reply	other threads:[~2005-04-29 21:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1113220089.2164.52.camel@sisko.sctweedie.blueyonder.co.uk>
     [not found] ` <1113244710.4413.38.camel@localhost.localdomain>
     [not found]   ` <1113249435.2164.198.camel@sisko.sctweedie.blueyonder.co.uk>
     [not found]     ` <1113288087.4319.49.camel@localhost.localdomain>
     [not found]       ` <1113304715.2404.39.camel@sisko.sctweedie.blueyonder.co.uk>
     [not found]         ` <1113348434.4125.54.camel@dyn318043bld.beaverton.ibm.com>
     [not found]           ` <1113388142.3019.12.camel@sisko.sctweedie.blueyonder.co.uk>
     [not found]             ` <1114207837.7339.50.camel@localhost.localdomain>
     [not found]               ` <1114659912.16933.5.camel@mindpipe>
     [not found]                 ` <1114715665.18996.29.camel@localhost.localdomain>
2005-04-29 13:52                   ` [Ext2-devel] [RFC] Adding multiple block allocation Suparna Bhattacharya
2005-04-29 17:10                     ` Mingming Cao
2005-04-29 19:42                       ` Mingming Cao
2005-04-29 20:57                         ` Andrew Morton
2005-04-29 21:12                           ` Mingming Cao [this message]
2005-04-29 21:34                             ` Andrew Morton
2005-04-30 16:00                       ` [Ext2-devel] " Suparna Bhattacharya
2005-04-29 18:45                     ` Badari Pulavarty
2005-04-29 23:22                       ` Mingming Cao
2005-04-30 16:10                         ` Suparna Bhattacharya
2005-04-30 17:11                           ` [Ext2-devel] " Suparna Bhattacharya
2005-04-30 18:07                             ` Mingming Cao
2005-05-02  4:46                               ` Suparna Bhattacharya
2005-04-30 16:52                       ` Suparna Bhattacharya
2005-04-30  0:33                     ` Mingming Cao
2005-04-30  0:44                     ` Mingming Cao
2005-04-30 17:03                       ` [Ext2-devel] " Suparna Bhattacharya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1114809139.10473.70.camel@localhost.localdomain \
    --to=cmm@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    --cc=sct@redhat.com \
    --cc=suparna@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).