[dm-devel] kernel 2.6 biosraid via device mapper - partition support

[Christophe Saout]

Am So, den 11.01.2004 schrieb Wilfried Weissmann um 16:21:

> i just started to investigate how biosraid support for the HPT37X 
> IDE-chipsets can be implemented in the 2.6 kernel. implementing the 
> basic raid levels (0, 1, 0+1, JBOD) seems to be pretty straight forward.

Yepp.

> this can be done by reading the raid signatures of the disks and then 
> pipeing the configuration through dmsetup or using the libdevmapper 
> library directly. what bothers me is the partition support. the number 
> of minor device nodes that are registered per mapped block device is 1. 
> this means that there is no way that the kernel does the 
> partition-handling by itself.

Yepp.

> the alternative is to do the partition 
> scanning in userspace and to use another device mapper layer to create 
> the partition device nodes. it appears that this was already suggested 
> by Christophe Varoqui ( http://lwn.net/Articles/13958/ ) but this 
> project is now idle.

Some people have written scripts to run in initrd for this the last
time. Using sfdisk -ld and shell scripts is very simple though not a
solution for everything, just for now.

> this also has the disadvantage that any changes in 
> the partitioning of the raid volume (e.g. by using *fdisk, distribution 
> installers, ...) require a manual re-invocation of the biosraid setup 
> tool. plus the whole code under linux/fs/partitions/... has to be 
> duplicated so that not only the dos partitioning scheme is supported, 
> but also BSD slices, x86 solaris, windows dynamic disks, ...

The plan for Linux 2.7 is to rip out partition detection from the kernel
and do everything in userspace (probably initramfs). So someone could
start by making the partition detection code a library.

The detection script/program could then be run from udev (the hotplug
interface) when a new block device is created.

I don't know what can be done about the ioctl that tells the kernel to
reread the partition table. It could either be dropped or make the
kernel create a hotplug event but that seems rather ugly.

> which way to go? is there another solution that i have missed?

I think you're on the right way. But you see there are still a lot of
issues to be discussed.