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
