From: "Jeff V. Merkey" <jmerkey@drdos.com>
To: jmerkey@galt.devicelogics.com
Cc: Jens Axboe <axboe@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.9-rc2 bio sickness with large writes
Date: Mon, 20 Sep 2004 11:12:39 -0600 [thread overview]
Message-ID: <414F0F87.9040903@drdos.com> (raw)
In-Reply-To: <20040917201604.GA12974@galt.devicelogics.com>
jmerkey@galt.devicelogics.com wrote:
Jens,
Can you explain the circumstances related to the bio->bi_size callback.
You stated (and I have observed)
that there may be callbacks from bi_end_io with bi_size set and that
these should be ignored and
return a value of 1.
Can you explain to me under what circumstances I am likely to see this
behavior? In other words, would
you explain the bio process start to finish with coalesced IO requests,
at least as designed. Also, the whole
page and offset sematics in the interface are also somewhat burdensome.
Wouldn't a more reasonable
interface for async IO be:
address
length
address
length
rather than
page structure
offset in page structure
page structure
offset in page structure
The hardware doesn't care about page mapping above it just needs to see
addresses (and not always 4 byte aligned addresses)
and lengths for building scatter gather lists. Forcing page sematics
seems a little orthagonal.
I can assume from the interface as designed that if you pass an offset
for a page that is not page aligned,
and ask for a 4K write, then you will end up dropping the data on the
floor than spans beyond the end of the page.
No offense, but this is **BUSTED** behavior for an asynch interface. The
whole page offset thing is a little
difficult to use and pushes needless complexity to someone just needing
to submit IO to the disk. I think this
is great for mmap for the VFS layer, and it dure makes it a lot easier
to submit IO for fs with the mmap layer,
but as a general purpose async layer on top of generic_make_request,
it's a little tough to use, IMHO.
Please advise,
Jeff
next prev parent reply other threads:[~2004-09-20 17:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-15 23:39 2.6.9-rc2 bio sickness with large writes Jeff V. Merkey
2004-09-16 6:34 ` Jens Axboe
2004-09-16 16:38 ` Jeff V. Merkey
2004-09-17 7:36 ` Jens Axboe
[not found] ` <20040917201604.GA12974@galt.devicelogics.com>
2004-09-20 17:12 ` Jeff V. Merkey [this message]
2004-09-20 18:09 ` Jens Axboe
2004-09-20 19:20 ` Jeff V. Merkey
2004-09-21 6:40 ` Jens Axboe
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=414F0F87.9040903@drdos.com \
--to=jmerkey@drdos.com \
--cc=axboe@suse.de \
--cc=jmerkey@galt.devicelogics.com \
--cc=linux-kernel@vger.kernel.org \
/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