From: Boaz Harrosh <bharrosh@panasas.com>
To: Jeff Garzik <jeff@garzik.org>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Jens Axboe <jens.axboe@oracle.com>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
linux-scs
Subject: [RFD] [PATCHSETS 0/2 0/2 0/5] Remove of blk_rq_append_bio usage
Date: Thu, 19 Mar 2009 16:21:49 +0200 [thread overview]
Message-ID: <49C254FD.7020202@panasas.com> (raw)
Hi all
In an effort to remove blk_rq_append_bio() and only use well published
block API, I would like to propose the below solution for OSD and exofs.
Current discussion has two sides:
* blk_make_request():
exofs and other non-block-based filesystems can use a bio, in which
case a well established block API should allow of allocating a request
given a bio.
* blk_rq_map_pages():
Let filesystems submit an array of page-pointers, and refrain from using
bio(s). bio(s) is a privilege of block-based filesystems only.
The first solution is trivial, robust, safe with minimum changes and impact.
It will allow any future directions easily.
I have also implemented a second approach with the use of a new
blk_rq_map_pages. It works, all exofs tests pass successfully just
as with today's code. But I hate it because:
* Jeff Garzik is working on a block-over-osd-object block-device.
I'm not sure of his plans, but sitting under block-layer at it's
prepare_fn routine, the most trivial solution is to pass the bio
as is to libosd. Otherwise he will need to copy and recopy all these
pages information.
Jeff please comment.
* Use of the in-kernel raid engines.
Current dm-raid engines are heavily bio based. If we want to tap into-that
(And we must) from exofs and pNFS-objects-layout we have no choice but to
use bio(s) and be able to submit bios.
* For any none trivial usage, even today. bio is more stable, robust
faster. and less code since it is already there.
Here is some code:
[PATCHSET 0/2] Allow append of kernel pointers to request
[PATCH 1/4] allow blk_rq_map_kern to append to requests
[PATCH 2/4] libosd: Use new blk_rq_map_kern
These two patches are not disputable and safe and should go in as is
even to 2.6.30. They remove one usage of blk_rq_append_bio from the
osd_initiator.
[PROPOSAL_1 0/2] blk_make_request()
[PATCH 3/4] [RFC] Export new blk_make_request() which takes bio and returns request
[PATCH 4/4] libosd: Use of new blk_make_request
This is option one above. Trivial, cosmetic, no core changes.
[PROPOSAL_2 0/5] blk_rq_map_pages()
[RFC 1/5] blk_rq_map_pages() new API
[RFC 2/5] libosd: Rename osd_req_write/read to osd_req_write/read_old
[RFC 3/5] libosd: No bio for you
[RFC 4/5] exofs: No bio for you
[RFC 5/5] libosd: Remove deprecated bio based API
This is option two above. Needs lots of core changes to exofs.
After patch 5/5 code runs well, all tests pass. There is
runtime bisectability problem, the exofs will not run between
[3/5]-[4/5].
Please advise
Boaz
next reply other threads:[~2009-03-19 14:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-19 14:21 Boaz Harrosh [this message]
2009-03-19 14:24 ` [PATCH A 1/2] allow blk_rq_map_kern to append to requests Boaz Harrosh
2009-03-19 14:27 ` [PATCH A 2/2] libosd: Use new blk_rq_map_kern Boaz Harrosh
2009-03-19 14:30 ` [RFC B 1/2] Export new blk_make_request() which takes bio and returns request Boaz Harrosh
2009-03-19 14:31 ` [RFC B 2/2] libosd: Use of new blk_make_request Boaz Harrosh
2009-03-19 14:33 ` [RFC C 1/5] blk_rq_map_pages() new API Boaz Harrosh
2009-03-19 14:34 ` [RFC C 2/5] libosd: Rename osd_req_write/read to osd_req_write/read_old Boaz Harrosh
2009-03-19 14:35 ` [RFC C 3/5] libosd: No bio for you Boaz Harrosh
2009-03-19 14:37 ` [RFC C 4/5] exofs: " Boaz Harrosh
2009-03-19 14:38 ` [RFC C 5/5] libosd: Remove deprecated bio based API Boaz Harrosh
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=49C254FD.7020202@panasas.com \
--to=bharrosh@panasas.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=jeff@garzik.org \
--cc=jens.axboe@oracle.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.