All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Cc: dm-devel@redhat.com, Alasdair Kergon <agk@redhat.com>
Subject: Re: [PATCH 0/6] dm: restrict conflicting table loads and improve queue initialization
Date: Mon, 24 May 2010 13:24:49 -0400	[thread overview]
Message-ID: <20100524172449.GB32389@redhat.com> (raw)
In-Reply-To: <4BFA4E4A.6060404@ct.jp.nec.com>

On Mon, May 24 2010 at  6:00am -0400,
Kiyoshi Ueda <k-ueda@ct.jp.nec.com> wrote:

> Hi Mike,
> 
> On 05/24/2010 06:44 AM +0900, Mike Snitzer wrote:

> > But this new series eliminates v7's locking between table_load() and
> > do_resume() -- fixed md->type made this possible.  So these changes
> > may be more desirable overall (adds some clearer exclusion and state
> > transitions that I feel help DM without being too restrictive).
> 
> Yes, I think it's reasonable.

OK.

> > This work has expanded in scope somewhat (based on Mikulas' suggestion
> > that I pursue more constrained table/device type switching to avoid
> > Kiyoshi's locking concerns).  A mapped_device now has a specific type
> > (md->type) that is managed in table_{load,clear} (see patch 3/6).
>  
> Cancelling the type by table_clear() keeps the code/model complex
> even after changing model.
> I think the feature to cancel the type is not required any userspace
> tools nor admins at least for now.  So dropping the feature and
> completely fixing the type at the first table loading time may be
> a good meeting point to make the kernel code simple.

I initially thought it best to keep table_clear() more "friendly".. so
as not to impose a user explicitly delete a DM device just to switch
from bio-based to request-based tables (or vice-versa).

But I think I've come full-circle:

- I'm not against imposing your suggestion (never reset md->type).
  Certainly keeps the DM code simpler! :)

- We don't know all existing userspace code -- people could be using
  DM's clear ioctl and we'd break their assumptions; but do we _really_
  care?  They'll adapt (they'd have to do a device delete, device
  create, table load).

> I had only a quick look, so I may find some more comments.  But I'd
> like to have more review after we reach an agreement about the basic
> implementation design above.

Yes, wish I had the restraint to avoid making dm_clear_md_type() work ;)

But pulling out that support will be easy and will also simplify other
code:
- will eliminate concern for "rq -> bio -> rq" in
  dm_init_request_based_queue()
- can remove dm_clear_request_based_queue()
- maybe more...

Thanks,
Mike

      reply	other threads:[~2010-05-24 17:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-23 21:44 [PATCH 0/6] dm: restrict conflicting table loads and improve queue initialization Mike Snitzer
2010-05-23 21:44 ` [PATCH 1/6] block: Adjust elv_iosched_show to return "none" for bio-based DM Mike Snitzer
2010-05-24  7:06   ` Jens Axboe
2010-05-23 21:44 ` [PATCH 2/6] dm ioctl: interlock resume and table clear Mike Snitzer
2010-05-24 17:08   ` Mike Snitzer
2010-05-23 21:44 ` [PATCH 3/6] dm: prevent table type changes after initial table load Mike Snitzer
2010-05-23 21:44 ` [PATCH 4/6 "v8"] dm: only initialize full request_queue for request-based device Mike Snitzer
2010-05-23 21:45 ` [PATCH 5/6] dm ioctl: introduce dm_get_verified_mdptr Mike Snitzer
2010-05-23 21:45 ` [PATCH 6/6] dm ioctl: introduce find_device_noinit Mike Snitzer
2010-05-24 10:00 ` [PATCH 0/6] dm: restrict conflicting table loads and improve queue initialization Kiyoshi Ueda
2010-05-24 17:24   ` Mike Snitzer [this message]

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=20100524172449.GB32389@redhat.com \
    --to=snitzer@redhat.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=k-ueda@ct.jp.nec.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.