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 3/4/24 17:21, Martin Wilck wrote:
> On Mon, 2024-03-04 at 12:00 +0100, Peter Rajnoha wrote:
>>
>> OK, makes sense. But I haven't looked at what implications this might
>> have for 99-systemd.rules yet, but we surely need to have that
>> covered
>> somehow.
>>
>> Maybe, now, I would probably even remove the mention about
>> DM_SUSPENDED
>> in 12-dm-permissions.rules, it looks superfluous there. We normally
>> set
>> perms based on names, not on DM_SUSPENDED state. I'm not sure why we
>> mentioned it there before.
>>
>> Do mpath rules still need to look at DM_SUSPENDED?
> 
> No, and yes :-)
> 
> If we remove the DISK_RO clause, DM_SUSPENDED and
> DM_UDEV_DISABLE_OTHER_RULES_FLAG (as input from 10-dm.rules) are
> equivalent for multipath. We'd be able to modify 11-dm-mpath.rules such
> that DM_SUSPENDED isn't used any more. The downside is that 11-dm-
> mpath.rules needs to modify DM_UDEV_DISABLE_OTHER_RULES_FLAG under
> certain conditions, and that DM_SUSPENDED is shorter and expresses the
> actual situation more intuitively. Therefore I don't love the idea to 
> replace use of DM_SUSPENDED with "DUDORF" in 11-dm-mpath.rules.
> 
> 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.

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.

-- 
Peter





[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux