Re: Re: LVM on dmraid breakage

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

 



On Thu, Aug 02, 2007 at 06:04:20PM -0400, Phillip Susi wrote:
Luca Berra wrote:
Two things come to mind
1) dmraid should use ioctl BLKPG_DEL_PARTITION, to clean up any eventual
partition table on component devices

How will this play out in terms of udev plug events? Can it be relied on that udev will process the disk first, before the partitions? If the partitions are deleted during the processing of the disk, does udev still try to process their add events? Will it then process the delete events? If so then this is problematic.
I really have no clue, fortunately dmraid is usually used for boot
disks, so it should be started before udev has a chance of messing with
devices. btw, md already does this, and redhat's initrd does this as
well.
The real solution to this is so simple.
Just ditch the partition detection code from the kernel, and move it to
userspace where it belongs.
For the time being use BLKPG_DEL_PARTITION, to undo what the kernel
should not have done.

2) lvm tool filter could be modified to check if a device has been
already claimed by device-mapper.

something along the lines of:
ioctl DM_LIST_DEVICES
while (...)
 ioctl DM_TABLE_DEPS

the above would probably require a cache.

I'd rather not see it that tightly coupled to dm. I was thinking perhaps of something involving udev attributes so that udev would know not to run pvscan on that device. Though it looks like pvscan also needs reworked so it plays nice with udev, being called to scan a given device as detected rather than looking for all well known physical device names in /dev.
i'd rather not see it coupled with udev :P
maybe i am limited, but i really fail to see how an event driven model
could be at all useful in this cases, and i am really convinced that the
effort needed to make i work is too high compared to possible benefits.
The biggest question being: How do you know you have scanned all
possible PV for a given volume group, and you have to activate it.
Anyway i still think my proposal is sensible and adapts to the current
paradigm of lvm2.

L.

--
Luca Berra -- bluca@xxxxxxxxxx
       Communication Media & Services S.r.l.
/"\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \

--
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