Re: kpartx and udev problem

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

 



2008-06-04_02:45:29-0400 Hannes Reinecke <hare@xxxxxxx>:

> Problem being the 'interesting' device-mapper design.
> Whenever a 'table create' operation is triggered from user-space, it's
> actually being broken down by the device-mapper library into 4 distinct
> operations:
> 1. create device dm-X
> 2. suspend device
> 3. load table definition
> 4. resume device
> 
> and you'll be getting an 'add' event for the first operation, and a
> 'change' event for the second and the forth operation.
> But clearly the 'add' event is pretty much pointless, as there is
> not table loaded at that time, so you wouldn't know what to do with
> it. And the device is locked between the second and the fourth
> operation, so kpartx would refuse to touch it.
> 
> So, in essence: 'add' is evil for device-mapper devices.
> Use the 'change' event and check if the dm-device is not suspended
> when you get the event.

Aha.  It took a little finagaling, but I finally got it.

I had to install an updated version of dmsetup, because the version on
etch doesn't support the options in the dmsetup_env script I pilfered.
I put my dmsetup in its own location, and compiled w/ LD_RUN_PATH set
to the location of its own local libdevmapper.so library, because I
didn't want to replace my system's libdevmapper.so, because I'm not
entirely sure of the consequences.

Everything appears to be working great.  Thanks!

-- 
Ron Peterson
Network & Systems Manager
Mount Holyoke College
http://www.mtholyoke.edu/~rpeterso
-
I wish my computer would do what I want it to do - not what I tell it to do.

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

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

  Powered by Linux