Message-ID: <49E2F84C.6080804@garzik.org>
Date: Mon, 13 Apr 2009 04:31:08 -0400
From: Jeff Garzik <jeff@garzik.org>
User-Agent: Thunderbird 2.0.0.21 (X11/20090320)
MIME-Version: 1.0
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
CC: bharrosh@panasas.com, tj@kernel.org, petkovbb@gmail.com,
       bzolnier@gmail.com, linux-kernel@vger.kernel.org, axboe@kernel.dk,
       linux-ide@vger.kernel.org
Subject: Re: [PATCHSET pata-2.6] ide: rq->buffer, data, special and misc	cleanups
References: <49D214E7.2040908@panasas.com>	<20090413163957P.fujita.tomonori@lab.ntt.co.jp>	<49E2EFBE.5000709@garzik.org> <20090413172143B.fujita.tomonori@lab.ntt.co.jp>
In-Reply-To: <20090413172143B.fujita.tomonori@lab.ntt.co.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2015
Lines: 46

FUJITA Tomonori wrote:
> On Mon, 13 Apr 2009 03:54:38 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> 
>> FUJITA Tomonori wrote:
>>> On Tue, 31 Mar 2009 16:04:39 +0300
>>> Boaz Harrosh <bharrosh@panasas.com> wrote:
>>>
>>>>> I
>>>>> just don't think bvec should be used outside of block/fs interface.
>>>>> As I wrote before, non-FS users have no reason to worry about bio.
>>>>> All it should think about is the requst it needs to issue and the
>>>>> memory area it's gonna use as in/out buffers.  bio just doesn't have a
>>>>> place there.
>>>>>
>>>> I don't understand what happens to all the people that start to work on the block
>>>> layer, they start getting defensive about bio being private to the request
>>>> level. But the Genie is out of the bag already (I know cats and bottles).
>>>> bio is already heavily used above the block layer from directly inside filesystems
>>>> to all kind of raid engines, DM MD managers, multi paths, integrity information ...
>>>>
>>>> Because bio is exactly that Ideal page carrier you are talking about.
>>> Wrong. multi path doesn't use bio. md accesses to the bio internal
>>> (it's not nice) and has the own way to carry pages. dm has the own
>>> mechanism on the top of bio. And bio doesn't work nicely for file
>>> systems such as btrfs, which handle multiple devices.
>>>
>>> Please stop your wrong argument 'bio is the ideal page carrier'.
>> 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.

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

	Jeff

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