Re: [RFC PATCH 5/7] dm udev rules: don't export and save DM_SUSPENDED

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux