Kay: * Can we have a sysfs event if the BLKRRPART ioctl() is called for a given device? This would help implementing more than 16 partitions for libata/scsi and also make partitioned fakeRAID devices easier to handle. * Is there any way to find out when partition detection by the kernel is finished? Or can we instruct the kernel not to detect partitions at all via sysfs?
Carl-Daniel Hailfinger wrote: > Olaf: You asked for a way to create one dm device per partition in > http://lkml.org/lkml/2006/8/10/42 . See the kpartx description below > for a solution. > > Andreas Jaeger wrote: >> Here're the agenda itmes that we plan to discuss tomorrow. Please >> send input/ask questions etc and I'll bring your input into the >> meeting. >> >> * /dev/hd removal: http://lkml.org/lkml/2006/8/9/285 > > Breaks everyone using partitions above hdX15. Two possible solutions: > - Use kpartx (and device mapper) for partitions sdX16 and greater > (ugly, but works. Booting from such partitions however requires > manual mapping in GRUB and LILO) > - Change minor number allocation for SCSI disks in the kernel > (unlikely to be accepted without great opposition) > > I'll test using kpartx and report back. This was easier than I thought. You need * partx from util-linux built with --enable-partx * kpartx from multipath-tools Once /sys/block/sdX/ and /sys/block/sdX/sdX[0-9]* appear, run # partx -d /dev/sdX # kpartx -a /dev/sdX and every partition will appear as usual, but in a slightly different place. /dev/sda1 becomes /dev/mapper/sda1 etc. The big difference is that you don't depend on minor number limits anymore (except the usual device-mapper bugs). So /dev/mapper/sda63 is indeed possible. This would all become a lot easier if we 1a. have a way to disable partition detection in the kernel via a knob or 1b. disable in-kernel partition detection by default and do it in userspace with "partx -a /dev/$DISK" when we get a disk_appears event. No change of tools needed, no user-visible changes. 2. (optional) switch to kpartx for partition detection at some point in the future when the tools can handle it. As long as udev works fine (and we get an event on BLKRRPART) the safest solution is 1b and it gives us all the freedom we need to implement the right solution. Regards, Carl-Daniel -- http://www.hailfinger.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
