All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel McNeil <daniel@osdl.org>
To: Suparna Bhattacharya <suparna@in.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
	"linux-aio@kvack.org" <linux-aio@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: AIO and DIO testing on 2.6.0-test7-mm1
Date: 20 Oct 2003 16:47:53 -0700	[thread overview]
Message-ID: <1066693673.22983.10.camel@ibm-c.pdx.osdl.net> (raw)
In-Reply-To: <20031020142727.GA4068@in.ibm.com>

On Mon, 2003-10-20 at 07:27, Suparna Bhattacharya wrote:
> On Fri, Oct 17, 2003 at 04:12:58PM -0700, Daniel McNeil wrote:
> > I've been doing some testing on 2.6.0-test7-mm1 with O_DIRECT and
> > AIO.  I wrote some tests to check the buffered i/o verses O_DIRECT
> > i/o races and O_DIRECT verses truncate.
> 
> Sounds very useful - thanks for doing this !
> 
> > 
> > I still had apply suparna's direct-io.c patch to prevent oopses.
> > Suparna, you said the patch was not the complete patch, do you have
> > the complete patch?
> 
> Not yet.
> A complete patch would need to address one more case that's rather
> tricky to solve -- the case where a single dio request covers an 
> allocated region followed by a hole.
> 
> Besides that there is a pending bug to address -- i.e to avoid
> dropping i_sem during the actual i/o in the case where we are
> extending the file (an intervening buffered write could extend
> i_size, exposing uninitialized blocks). For AIO-DIO this means 
> forcing the i/o to be synchronous for this case (as also for 
> the case where we are overwriting an allocated region followed 
> by a hole). Until we can use i/o barriers.
> 
> I was playing with a retry-based implementation for AIO-DIO,
> where the first (tricky) case above becomes simple to handle ...
> But didn't get a chance to work much on this during the last 
> few days. I actually do have a patch, but there are occasional 
> hangs with a lot of AIO-DIO writes to an ext3 filesystem in 
> particular, that I can't explain as yet.
> 
> Do your testcases cover any of these cases already ?
> 
> Regards
> Suparna
> 

I was hoping that my test cases would hit some of these potential AIO
verses buffered write (growing the file and filling in holes) races.
My tests always write zeroes and holes should always return zeroes, so
the check makes sure that the data is always zero. I am planning on
updating the tests to have more readers and maybe more writers to
check if we ever see uninitialized data.  I am starting to test on
2.6-test8 and will let you know how it goes.

Daniel


  reply	other threads:[~2003-10-20 23:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-17 23:12 AIO and DIO testing on 2.6.0-test7-mm1 Daniel McNeil
2003-10-18  0:24 ` Andrew Morton
2003-10-20 14:27 ` Suparna Bhattacharya
2003-10-20 23:47   ` Daniel McNeil [this message]
2003-10-21 12:11     ` Patch for Retry based AIO-DIO (Was AIO and DIO testing on 2.6.0-test7-mm1) Suparna Bhattacharya
2003-10-23  0:40       ` Daniel McNeil
2003-10-23 10:49         ` Suparna Bhattacharya
2003-10-23 13:50           ` Suparna Bhattacharya
2003-10-23 22:59             ` Andrew Morton
2003-10-23 23:20               ` Patch for Retry based AIO-DIO (Was AIO and DIO testing on2.6.0-test7-mm1) Adrian Bunk
2003-10-23 23:25                 ` Andrew Morton
2003-10-23 23:37                   ` Patch for Retry based AIO-DIO (Was AIO and DIO testingon2.6.0-test7-mm1) Adrian Bunk
2003-10-23 23:46                     ` Andrew Morton
2003-10-24  0:34                       ` Patch for Retry based AIO-DIO (Was AIO and DIOtestingon2.6.0-test7-mm1) Adrian Bunk
2003-10-26 11:57                       ` Adrian Bunk
2003-10-26 12:08                         ` Russell King
2003-10-26 12:17                           ` Adrian Bunk
2003-10-26 13:00                             ` Russell King
2003-10-23 23:22               ` Patch for Retry based AIO-DIO (Was AIO and DIO testing on 2.6.0-test7-mm1) Dan Kegel

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=1066693673.22983.10.camel@ibm-c.pdx.osdl.net \
    --to=daniel@osdl.org \
    --cc=akpm@osdl.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.