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

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

[Martin Wilck]

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?

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.

Regards,
Martin 

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

[Demi Marie Obenour]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

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.

> 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?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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