[<prev] [next>] [day] [month] [year] [list]
Message-ID: <491063E5.9060805@ct.jp.nec.com>
Date: Tue, 04 Nov 2008 10:01:57 -0500
From: Kiyoshi Ueda <k-ueda@...jp.nec.com>
To: Nikanth Karthikesan <KNikanth@...ell.com>
CC: nikanth@...il.com, agk@...hat.com, j-nomura@...jp.nec.com,
"<Andi Kleen" <andi@...stfloor.org>,
James.Bottomley@...senpartnership.com, jens.axboe@...cle.com,
dm-devel@...hat.com, "<Milan Broz" <mbroz@...hat.com>,
knikanth@...e.de, linux-kernel@...r.kernel.org,
linux-scsi@...r.kernel.org, Kiyoshi Ueda <k-ueda@...jp.nec.com>
Subject: Re: [dm-devel] [PATCH 10/13] dm: add core functions for request-based
dm
Hi Nikanth,
Nikanth Karthikesan wrote:
> Hi Kiyoshi
>
>>>> On 10/28/2008 at 09:30 PM, Kiyoshi Ueda <k-ueda@...jp.nec.com> wrote:
>> Hi Nikanth,
>>
>> On Fri, 24 Oct 2008 13:14:50 +0530, "Nikanth K" wrote:
>>> On Fri, Sep 12, 2008 at 8:16 PM, Kiyoshi Ueda wrote:
>>> <snip>
>>>
>>>> +static int dm_make_request(struct request_queue *q, struct bio *bio)
>>>> +{
>>>> + struct mapped_device *md = (struct mapped_device *)q->queuedata;
>>>> +
>>>> + if (unlikely(bio_barrier(bio))) {
>>>> + bio_endio(bio, -EOPNOTSUPP);
>>>> + return 0;
>>>> + }
>>>> +
>>> <snip>
>>>
>>> Why not add barrier support in the beginning itself, so that targets
>>> can be developed with barriers in mind? At least can we make the target
>>> to return error, instead of the core?
>> Currently, there is no barrier support in dm, not only request-based.
>> Barrier support is a different feature in the next step, I think.
>
> But there are some works in that direction to add support for barriers in dm.
> That is why I think building request-based dm with barriers from the
> ground up might be a good idea.
I agree, if I or other people have a time to implement barrier support
for request-based dm.
But I think the some works you mentioned above are:
- Andi Kleen: barrier support for linear (single device)
- Milan Broz: full barrier support in dm core (no target patch)
so there is no barrier support work for dm-multipath yet.
Current request-based target is only dm-multipath, so we won't have
any feature regression even if request-based dm-multipath gets in.
And I don't have much time to implement barrier support for
request-based dm-multipath now, so I'd like to consider it as
the next step.
Thanks,
Kiyoshi Ueda
--
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/
Powered by blists - more mailing lists