linux-kernel - Re: [PATCHSET pata-2.6] ide: rq->buffer, data, special and misc cleanups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1239632218.3278.14.camel@mulgrave.int.hansenpartnership.com>
Date:	Mon, 13 Apr 2009 14:16:58 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	bharrosh@...asas.com, tj@...nel.org, petkovbb@...il.com,
	bzolnier@...il.com, linux-kernel@...r.kernel.org, axboe@...nel.dk,
	linux-ide@...r.kernel.org
Subject: Re: [PATCHSET pata-2.6] ide: rq->buffer, data, special and
	misc	cleanups

On Mon, 2009-04-13 at 04:31 -0400, Jeff Garzik wrote:
> >> What is the multi-device problem with bio?
> > 
> > Well, if it works nicely, I guess that we don't have something like
> > drivers/dm/{dm-bio-record.h, dm-bio-list.h}, btrfs_multi_bio struct,
> > or md's own page carrier?
> 
> It was an honest question.  I am seeking information, not denying your 
> argument.

I think it wasn't quite designed like that.  The original designed
carrier of pages was the bio_vec array.   The bio was designed to carry
the bio_vec into the top end of block.  bio_vec is incredibly
lightweight (it's more like a scatterlist), but bio is a lot heavier and
now has a lot of quirky initialisers (like call backs and merge counts)
that need to be set correctly, making it a more difficult think to use
generically.   bio is really designed to be the merge unit for requests
not a generic carrier of pages.

The final irony is that most of the page list mappings we do want to go
straight to requests, making the bio complexity even more superfluous.

> What, specifically, is this multi-device problem with bio, please?

The multi device problem is that it's very hard to split a bio up again
once we've assembled it, so if you get a single bio whose I/O crosses
multiple devices in md or dm, there's a lot of work that has to go on
behind the scenes to get the split to happen because we need one bio per
underlying device that we send I/O to.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/