On Tue, 2024-03-05 at 09:19 +0100, Peter Rajnoha wrote:
> On 3/4/24 17:21, Martin Wilck wrote:
> >
> > My personal take on this is that 11-dm-mpath.rules actually belongs
> > to
> > device-mapper (being executed before 13-dm-disk.rules), even though
> > it's not maintained in the lvm2 repository. As such, it should be
> > allowed to access dm-internal flags like DM_SUSPENDED.
> > Not that's not a problem with this patch; the multipath rules can
> > just
> > access .DM_SUSPENDED instead of DM_SUSPENDED.
>
> Within DM and DM-subsystem rules, it's OK to use DM_SUSPENDED, if
> needed.
I gather that you agree that 11-dm-mpath.rules represents a "DM
subsystem" rule set?
>
> We should just hide it from all the "other" rules so they don't need
> to
> bother. For them (right now), it's either "usable" or "unusable"
> device
> for whatever reason behind and we (DM+DM-subystem) should reimport
> whatever is needed for the state/set of variables that others may
> use,
> to stay sane. Of course, we can do this only for the state that we
> own.
>
> As we discussed before, this can be extended to making a difference
> among "usable", "temporarily unusable" (so reimport the
> state/variables
> needed) and "completely unusable" state for others.
Yeah, but that's future work, and I doubt that it makes sense to invest
much effort into it. I definitely wouldn't want to tie this to the
current patch set.
As mentioned previously, it might make sense to introduce a flag that
expresses something like "you can access this device, but you don't
need to" (DISK_RO={0,1} case, for example). But then, we already have
DM_ACTIVATION to express the opposite ("you must have a look at this
device, its properties have changed"). I wonder if you consider
DM_ACTIVATION a dm-internal property?
Thanks
Martin
