[v2,0/4] Diskseq support in device-mapper

Message

Demi Marie Obenour June 24, 2023, 11:09 p.m. UTC

This work aims to allow userspace to create and destroy device-mapper
devices in a race-free way.

Changes since v1:

- Potentially backwards-incompatible changes to device-mapper now
  require userspace opt-in.
- The code has been tested: I have a block script written in C that uses
  these changes to successfully boot a Xen VM.
- The core block layer is completely untouched.  Instead of exposing a
  block device inode directly to userspace, device-mapper ioctls that
  create a block device now return that device's diskseq.  Userspace can
  then use that diskseq to safely open the device.  Furthermore, ioctls
  that operate on an existing device-mapper device now accept a diskseq
  parameter, which can be used to prevent races.

Demi Marie Obenour (4):
  dm ioctl: Allow userspace to opt-in to strict parameter checks
  dm ioctl: Allow userspace to provide expected diskseq
  dm ioctl: Allow userspace to suppress uevent generation
  dm ioctl: inform caller about already-existing device

 drivers/md/dm-core.h          |   2 +
 drivers/md/dm-ioctl.c         | 351 ++++++++++++++++++++++++++++------
 drivers/md/dm.c               |   5 +-
 include/linux/device-mapper.h |   2 +-
 include/uapi/linux/dm-ioctl.h |  90 ++++++++-
 5 files changed, 382 insertions(+), 68 deletions(-)

Comments

Martin Wilck Jan. 15, 2024, 5:56 p.m. UTC | #1

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

Demi Marie Obenour Jan. 15, 2024, 9:44 p.m. UTC | #2

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?

Martin Wilck Jan. 16, 2024, 8 a.m. UTC | #3

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