linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  parent reply	other threads:[~2008-11-04 15:02 UTC|newest]

Thread overview: 26+ 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:40 ` [PATCH 01/13] block: add request update interface Kiyoshi Ueda
2008-09-12 14:41 ` [PATCH 02/13] block: add request submission interface Kiyoshi Ueda
2008-09-14 13:10   ` Boaz Harrosh
2008-09-16 16:06     ` Kiyoshi Ueda
2008-09-16 17:02       ` Jens Axboe
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:43 ` [PATCH 04/13] scsi: exports busy status 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:44 ` [PATCH 06/13] dm: remove unused DM_WQ_FLUSH_ALL Kiyoshi Ueda
2008-09-12 14:44 ` [PATCH 07/13] dm: tidy local_init 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 ` [PATCH 09/13] dm: add target interfaces " Kiyoshi Ueda
2008-09-12 14:46 ` [PATCH 10/13] dm: add core functions " Kiyoshi Ueda
2008-10-24  7:44   ` [dm-devel] " Nikanth K
2008-10-28 16:00     ` Kiyoshi Ueda
     [not found]     ` <490FB852.3FEE.00C5.1@novell.com>
     [not found]       ` <49102C03020000C50002E257@victor.provo.novell.com>
2008-11-04 15:01         ` Kiyoshi Ueda [this message]
2008-09-12 14:46 ` [PATCH 11/13] dm: enable " Kiyoshi Ueda
2008-10-24  7:52   ` [dm-devel] " Nikanth K
2008-10-28 16:02     ` Kiyoshi Ueda
2008-09-12 14:46 ` [PATCH 12/13] dm: reject I/O violating new queue limits Kiyoshi Ueda
2008-09-12 14:47 ` [PATCH 13/13] dm-mpath: convert to request-based Kiyoshi Ueda
2008-10-24  7:55   ` [dm-devel] " Nikanth K
2008-10-28 16:03     ` 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=James.Bottomley@hansenpartnership.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 \
    --cc=nikanth@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).