On 04/25/2017 05:52 PM, Benjamin Marzinski wrote:
On Tue, Apr 25, 2017 at 12:12:25PM +0200, Steffen Maier wrote:
On 04/25/2017 12:39 AM, Benjamin Marzinski wrote:
When users run kpartx, they would naturally assume that when it
completes, the devices have been created. However, kpartx runs in async
mode by default. This seems like it is likely to trip up users. So,
switch the default to sync mode, add a -n option to enable async mode,
and set async mode when kpartx is called by the udev rules.
diff --git a/kpartx/kpartx.c b/kpartx/kpartx.c
+ printf("\t-n nosync mode. Return before the partitions are created\n");
diff --git a/kpartx/kpartx.rules b/kpartx/kpartx.rules
@@ -40,6 +40,6 @@ ENV{DM_NR_VALID_PATHS}=="0", GOTO="kpartx_end"
ENV{ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG1"
ENV{DM_SUBSYSTEM_UDEV_FLAG1}=="1", GOTO="kpartx_end"
ENV{DM_STATE}!="SUSPENDED", ENV{DM_UUID}=="mpath-*", \
- RUN+="/sbin/kpartx -u -p -part /dev/$name"
+ RUN+="/sbin/kpartx -un -p -part /dev/$name"
I understand this was async before and is now still async after the default
change in kpartx. However, I'm wondering in general how one would "wait" for
kpartx mappings, since I suppose a "udevadm settle" would not suffice.
Dracut probably does not care because it would loop until its required
root-fs devices have appeared.
I'm pretty sure that it is inherently impossible in the general case.
There is no way to know when the uevent will occur, and until the uevent
occurs, there would be no way that udev settle could possibly help. You
indeed
can know that a dm device has been set up when the first change event
for that device occurs. So, if you knew a device was coming, you could
wait for the change event. Multipathd currently listens for change
events to know when a multipath device has been fully initialized.
For partition devices explicitly, say you just manually ran multipath to
create a multipath device, and want to know that your partition devices
exist before going on. You could manually run kpartx in the now-default
sync mode, and when it returned, you would know that the devices were
there. However, your kpart call would be racing with the udev version,
so it's possible that kpartx would return with an error because it tried
to create the device and failed because the device already existed. The
good news is that it would continue to try with the rest of the devices,
so it really won't return until they all are there. If it is important
to you, we could add a flag to kpartx to not return an error if a create
fails because the device currently exists.
Currently I have no real need for such addition, just wanted to
understand the implications.
Thanks for your explanation!
--
Mit freundlichen Grüßen / Kind regards
Steffen Maier
Linux on z Systems Development
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
