From: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
To: Nikanth Karthikesan <KNikanth@novell.com>
Cc: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>,
linux-scsi@vger.kernel.org, knikanth@suse.de,
linux-kernel@vger.kernel.org, dm-devel@redhat.com,
"<Andi Kleen" <andi@firstfloor.org>,
jens.axboe@oracle.com, j-nomura@ce.jp.nec.com, agk@redhat.com,
"<Milan Broz" <mbroz@redhat.com>
Subject: Re: [PATCH 10/13] dm: add core functions for request-based dm
Date: Tue, 04 Nov 2008 10:01:57 -0500 [thread overview]
Message-ID: <491063E5.9060805@ct.jp.nec.com> (raw)
In-Reply-To: <49102C03020000C50002E257@victor.provo.novell.com>
Hi Nikanth,
Nikanth Karthikesan wrote:
> Hi Kiyoshi
>
>>>> On 10/28/2008 at 09:30 PM, Kiyoshi Ueda <k-ueda@ct.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
WARNING: multiple messages have this Message-ID (diff)
From: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
To: Nikanth Karthikesan <KNikanth@novell.com>
Cc: nikanth@gmail.com, agk@redhat.com, j-nomura@ce.jp.nec.com,
"<Andi Kleen" <andi@firstfloor.org>,
James.Bottomley@hansenpartnership.com, jens.axboe@oracle.com,
dm-devel@redhat.com, "<Milan Broz" <mbroz@redhat.com>,
knikanth@suse.de, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org, Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Subject: Re: [dm-devel] [PATCH 10/13] dm: add core functions for request-based dm
Date: Tue, 04 Nov 2008 10:01:57 -0500 [thread overview]
Message-ID: <491063E5.9060805@ct.jp.nec.com> (raw)
In-Reply-To: <49102C03020000C50002E257@victor.provo.novell.com>
Hi Nikanth,
Nikanth Karthikesan wrote:
> Hi Kiyoshi
>
>>>> On 10/28/2008 at 09:30 PM, Kiyoshi Ueda <k-ueda@ct.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
next prev parent reply other threads:[~2008-11-04 15:01 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-12 14:38 [PATCH 00/13] request-based dm-multipath Kiyoshi Ueda
2008-09-12 14:38 ` Kiyoshi Ueda
2008-09-12 14:40 ` [PATCH 01/13] block: add request update interface Kiyoshi Ueda
2008-09-12 14:40 ` Kiyoshi Ueda
2008-09-12 14:41 ` [PATCH 02/13] block: add request submission interface Kiyoshi Ueda
2008-09-12 14:41 ` Kiyoshi Ueda
2008-09-14 13:10 ` Boaz Harrosh
2008-09-16 16:06 ` Kiyoshi Ueda
2008-09-16 16:06 ` Kiyoshi Ueda
2008-09-16 17:02 ` Jens Axboe
2008-09-16 18:12 ` Kiyoshi Ueda
2008-09-16 18:12 ` Kiyoshi Ueda
2008-09-12 14:42 ` [PATCH 03/13] mm: lld busy status exporting interface Kiyoshi Ueda
2008-09-12 14:42 ` Kiyoshi Ueda
2008-09-12 14:43 ` [PATCH 04/13] scsi: exports busy status Kiyoshi Ueda
2008-09-12 14:43 ` Kiyoshi Ueda
2008-09-12 14:43 ` [PATCH 05/13] block: add a queue flag for request stacking support Kiyoshi Ueda
2008-09-12 14:43 ` Kiyoshi Ueda
2008-09-12 14:44 ` [PATCH 06/13] dm: remove unused DM_WQ_FLUSH_ALL Kiyoshi Ueda
2008-09-12 14:44 ` Kiyoshi Ueda
2008-09-12 14:44 ` [PATCH 07/13] dm: tidy local_init Kiyoshi Ueda
2008-09-12 14:44 ` Kiyoshi Ueda
2008-09-12 14:45 ` [PATCH 08/13] dm: add kmem_cache for request-based dm Kiyoshi Ueda
2008-09-12 14:45 ` Kiyoshi Ueda
2008-09-12 14:45 ` [PATCH 09/13] dm: add target interfaces " Kiyoshi Ueda
2008-09-12 14:45 ` Kiyoshi Ueda
2008-09-12 14:46 ` [PATCH 10/13] dm: add core functions " Kiyoshi Ueda
2008-09-12 14:46 ` Kiyoshi Ueda
2008-10-24 7:44 ` [dm-devel] " Nikanth K
2008-10-28 16:00 ` Kiyoshi Ueda
2008-10-28 16:00 ` [dm-devel] " Kiyoshi Ueda
[not found] ` <490FB852.3FEE.00C5.1@novell.com>
2008-11-04 5:33 ` [PATCH 10/13] dm: add core functions forrequest-based dm Nikanth Karthikesan
2008-11-04 15:01 ` Kiyoshi Ueda [this message]
2008-11-04 15:01 ` [dm-devel] [PATCH 10/13] dm: add core functions for request-based dm Kiyoshi Ueda
2008-09-12 14:46 ` [PATCH 11/13] dm: enable " Kiyoshi Ueda
2008-09-12 14:46 ` Kiyoshi Ueda
2008-10-24 7:52 ` [dm-devel] " Nikanth K
2008-10-28 16:02 ` Kiyoshi Ueda
2008-10-28 16:02 ` [dm-devel] " Kiyoshi Ueda
2008-09-12 14:46 ` [PATCH 12/13] dm: reject I/O violating new queue limits Kiyoshi Ueda
2008-09-12 14:46 ` Kiyoshi Ueda
2008-09-12 14:47 ` [PATCH 13/13] dm-mpath: convert to request-based Kiyoshi Ueda
2008-09-12 14:47 ` Kiyoshi Ueda
2008-10-24 7:55 ` [dm-devel] " Nikanth K
2008-10-28 16:03 ` Kiyoshi Ueda
2008-10-28 16:03 ` [dm-devel] " Kiyoshi Ueda
2008-09-14 13:17 ` [PATCH 00/13] request-based dm-multipath 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=491063E5.9060805@ct.jp.nec.com \
--to=k-ueda@ct.jp.nec.com \
--cc=KNikanth@novell.com \
--cc=agk@redhat.com \
--cc=andi@firstfloor.org \
--cc=dm-devel@redhat.com \
--cc=j-nomura@ce.jp.nec.com \
--cc=jens.axboe@oracle.com \
--cc=knikanth@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mbroz@redhat.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.