http://bugzilla.suse.com/show_bug.cgi?id=912170
--- Comment #17 from Jeff Mahoney ---
Andrei, I know cryptsetup creates a normal device mapper device. Prior to doing
that, it *also* sets up a temporary device.
Further, the "convenience" names are the ones that util-linux and btrfsprogs
have automatically translated from dm-# names, so if you have a problem there,
please take it up with them. The /dev/mapper/volname naming has been in place
for a very long time and *nobody* uses the /dev/dm-# names directly unless
forced to do so.
This is an issue for btrfs because of the multi device support. It reports the
device name via the kernel's mechanism to allow file systems to self-report. It
*could* do that by using bdevname() or something, but that would always return
the dm-# name. Instead, we try to take the path of least surprise, which would
be responding with the /dev/mapper name. That's what users use to mount it
(directly or indirectly via UUID=/LABEL=/whatever) and that's what they expect
to see in /proc/mounts, etc. Lastly, the /dev/mapper names are a convention,
and mapping them automatically in the kernel is essentially implementing policy
in the kernel, which there are longstanding rules against doing.
So, simply reverting that fix isn't the answer. It fixed a real issue reported
by a real customer. Redefining the scope of the problem to paper over it
doesn't make that go away.
Robert, I suspect that the $ENV{DM_NAME}=*? rule is getting executed. That's
what Andrei's strace seems to demonstrate. The issue is that it's executed and
the link that it expects to use (and that should have been created via the
SYMLINK rule in the DM rules) hasn't been created. Your suggestion may clean up
that rule a little bit to avoid multiple gotos but it's functionally equivalent
to the suggestion in comment #2 that is wrong.
This rule *should work fine.*
The issue seems to be that the symlink isn't created. The cookies that DM
creates are used, AFAIK, for finer-grained synchronization, so that DM doesn't
need to do something like a "udevadm settle" or whatever the command is these
days that will wait for *all* events to be processed when it only cares about
the device it just created.
--
You are receiving this mail because:
You are on the CC list for the bug.