On 3/5/24 09:47, Martin Wilck wrote:
> On Tue, 2024-03-05 at 09:19 +0100, Peter Rajnoha wrote:
>> 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?
>
Sure, of course.
>>
>> 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.
>
I agree.
> 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?
Well, we added DM_ACTIVATION as a helper primarily for DM and DM-subsys
rules to have a way to identify when the actual (re)activation happens,
or the "add" trigger on coldplug.
I think it was 69-dm-lvm.rules (or 69-dm-lvm-metad.rules at that time)
where we needed to run pvscan only right after the DM dev is activated
and hence avoiding running costly pvscan uselessly where it doesn't matter.
If there's anyone else out there with similar use case, I think that
checking DM_ACTIVATION might be useful. But it's true it is not
advertised and shouted out somehow publicly yet.
Usually, all the other rules are interested in rescanning all the other
"foreign" state and attributes that is out of DM's hands, which means
they know exactly when to do the scan or not or any other actions, it
depends on what attributes are they watching for.
DM_ACTIVATION is very useful to know when stacking devices on top of DM
though, so a time when to activate the layer above. So yes, this
variable might be useful for other to look for too.
--
Peter
