In setting up a partitioned array as the boot disk and using a nash initrd to find the root file system by volume label, I see a delay in the appearance of the /dev/md_d0p partitions in /proc/partitions. When the mdadm --assemble command completes, only /dev/md_d0 is visible. Since the raid partitions are not visible after the assemble, the volume label search will not consult them in looking for the root volume and the boot gets aborted. When I run a similar assemble command while up multi-user in a friendlier debug environment I see the same effect and observe that pretty much any access of /dev/md_d0 has the side effect of then making the /dev/md_d0p partitions visible in /proc/partitions.

I tried a few experiments changing the --assemble code in mdadm. If I open() and close() /dev/md_d0 after assembly *before* closing the file descriptor which the assemble step used to assemble the array, there is no effect. Even doing a BLKRRPART ioctl call on the assembly fd or the newly opened fd have no effect. The kernel prints "unknown partition" diagnostics on the console. However, if the assembly fd is first close()'d, a simple open() of /dev/md_d0 and immediate close() of that fd has the side effect of making the /dev/md_d0p partitions visible and one sees the console disk partitioning confirmation from the kernel as well.

Adding the open()/close() after assembly within mdadm solves my problem, but I thought I'd raise the issue on the list as it seems there is a bug somewhere. I see in the kernel md driver that the RUN_ARRAY ioctl() calls do_md_run() which calls md_probe() which calls add_disk() and I gather that this would normally have the side effect of making the partitions visible. However, my experiments at user level seem to imply that the array isn't completely usable until the assembly file descriptor is closed, even on return from the ioctl(), and hence the kernel add_disk() isn't having the desired partitioning side effect at the point it is being invoked.

This is all with kernel 2.6.18 and mdadm 2.3.1
--
Mike Accetta

ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to