Re: [dm-devel] [PATCH v2 0/4] Diskseq support in device-mapper

[Martin Wilck]

On Mon, 2024-01-15 at 16:44 -0500, Demi Marie Obenour wrote:
> On Mon, Jan 15, 2024 at 06:56:16PM +0100, Martin Wilck wrote:
> > On Sat, 2023-06-24 at 19:09 -0400, Demi Marie Obenour wrote:
> > > This work aims to allow userspace to create and destroy device-
> > > mapper
> > > devices in a race-free way.
> > 
> > The discussion about this feature seems to have stalled ... will
> > there
> > be a v3 of this series any time soon?
> 
> I’m still interested in a v3, but it might take a while.  If you are
> willing and able to do it first, I recommend that you do so.

No, I was just trying to understand the status.

> 
> > Also, I am wondering what should happen if a device-mapper table is
> > changed in a SUSPEND/LOAD/RESUME cycle. Such operations can change
> > the
> > content of the device, thus I assume that the diskseq should also
> > change. But AFAICS this wasn't part of your patch set.
> > 
> > In general, whether the content changes in a reload operation
> > depends
> > on the target. The multipath target, for example, reloads
> > frequently
> > without changing the content of the dm device. An ever-changing
> > diskseq
> > wouldn't make a lot of sense for dm-multipath. But I doubt we want
> > to
> > start making distinctions on this level, so I guess that diskseq
> > and
> > multipath just won't go well together.
> 
> Should this be controlled by userspace?

Personally, I don't think so, but I guess this deserves a broader
discussion.

IMO users who want to benefit from the diskseq feature would not want
to be surprised by device-mapper devices changing under them, and would
also not want to have some block devices with diskseq semantics and
others without. Therefore I believe that it's sufficient to be able to
have some global switch to enable or disable the use of diskseq. But
I've only learned about this feature pretty recently, so I may easily
be misunderstanding something.

Martin