From: Zach Brown <zach.brown@oracle.com>
To: suparna@in.ibm.com
Cc: akpm@osdl.org, sct@redhat.com, mason@suse.com,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org,
kenneth.w.chen@intel.com, pbadari@us.ibm.com,
linux-kernel@vger.kernel.org, sonny@burdell.org
Subject: Re: [RFC][WIP] DIO simplification and AIO-DIO stability
Date: Thu, 23 Feb 2006 17:21:08 -0800 [thread overview]
Message-ID: <43FE5F84.4000001@oracle.com> (raw)
In-Reply-To: <20060223072955.GA14244@in.ibm.com>
Suparna Bhattacharya wrote:
> A recent AIO-DIO bug reported by Kenneth Chen, came very close
> to being the proverbial last straw for me.
Me too, though I found out about it from a different path. Our QA guys
were pulling drives under load and it got stuck. Trying to fix that bug
(io error setting dio->result to -EIO stops finished_one_bio() from
calling aio_complete()) without introducing other regressions involved
an incredible amount of squinting and head scratching. In wandering
around I found what seem to be other additional bugs:
- errors that hit after dio->result is sampled in the buffered fallback
case are lost. dio->result should be checked again after waiting.
- a few paths try to do arithmetic with dio->result assuming it's the
number of bytes transferred when it could be -EIO.
- the AIO path seems to forget to check dio->page_errors, but I didn't
look very hard to see what that means.
- the AIO bio completion paths don't populate dio->bio_list so reaping
doesn't happen in the AIO issuing case.. maybe that's intentional?
> It would be quite pointless (and painful!), if the rewrite ends up becoming
> just as tricky and error prone as before. Such a patch will need a very
> close critical review by many sharp eyes, to avoid disrupting the current
> state of stability.
So, I'm all for wringing the current bugs and confusion out of the
current code. But the words "a patch" and "rewrite" terrify me. It
seems much more prudent to make progress with incremental patches that
can be tested and reviewed. Especially if that is tied to writing tests
as changes are made.
Let me think harder about the specific proposals..
- z
next prev parent reply other threads:[~2006-02-24 1:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-23 7:29 [RFC][WIP] DIO simplification and AIO-DIO stability Suparna Bhattacharya
2006-02-23 19:12 ` Wendy Cheng
2006-02-24 11:53 ` Suparna Bhattacharya
2006-02-24 15:51 ` Wendy Cheng
2006-02-24 0:39 ` Badari Pulavarty
2006-02-24 1:13 ` Andrew Morton
2006-02-24 11:25 ` Suparna Bhattacharya
2006-02-24 1:01 ` Chris Mason
2006-02-24 9:37 ` Suparna Bhattacharya
2006-02-24 1:21 ` Zach Brown [this message]
2006-02-24 11:12 ` Suparna Bhattacharya
2006-02-24 18:09 ` Badari Pulavarty
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=43FE5F84.4000001@oracle.com \
--to=zach.brown@oracle.com \
--cc=akpm@osdl.org \
--cc=kenneth.w.chen@intel.com \
--cc=linux-aio@kvack.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@suse.com \
--cc=pbadari@us.ibm.com \
--cc=sct@redhat.com \
--cc=sonny@burdell.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 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).