[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [PATCH 0/6] dm: restrict conflicting table loads and improve queue initialization

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.


> > 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
- will eliminate concern for "rq -> bio -> rq" in
- can remove dm_clear_request_based_queue()
- maybe more...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]