Created attachment 26784 [details] config 2.6.35-rc3 I'm running multiple md/raid devices, mostly raid-1, some partitioned, some not, on the same set of four spindles, identically partitioned such that partitions sd[abcd]N assemble into an md/raid device. With kernel 2.6.34, the system boots fine, the md partition devices (mdXpY) show up in /dev, and everything mounts normally. With kernel 2.6.35-rc3, localmount says it can't find various labeled filesystems to mount. A bit of investigation later, I realize the only /dev/mdXpY devices showing up are the ones for the rootfs, assembled from the kernel command line. The unpartitioned md devices and the other partitioned md main devices (/dev/mdX) show up, and gdisk (the partitions are GPT, not legacy MBR) sees the partition table, which appears to be intact on the devices, but the /dev/mdXpY devices themselves (other than for the rootfs assembled from the kernel command line) don't show up. System is a dual Opteron 290, Tyan s2885 mobo, 6 gigs RAM, running Gentoo/~amd64. All of userspace was recently fresh-rebuilt on gcc-4.5.0, which was used to compile 2.6.35-rc3 as well, tho the 2.6.34 kernel was compiled earlier with gcc 4.4.3. Related userspace apps: mdadm 3.1.2, util-linux 2.17.2, udev 154. Filesystems are reiserfs (until btrfs can safely replace it). md/raid metadata version 0.90. As far as I can see, the only thing creating the mdXpY devices is the kernel/udev, no funny gentoo or local udev rules or initscript voodoo in that regard. The kernel config should be attached and I can git bisect. But first: 1) This isn't already known and bisected, is it? New report? 2) No known data corruption bombs waiting to blow up the unwary git bisector in the 2.6.35 development series, I hope? (That's why I wait until rc2 or so before testing, any data corruption bombs should be fixed by then, hopefully.)
I'll mark this as a regression. No, I haven't seen previous reports of this. Yes please, a bisection would be great. No, it won't eat your disks :)
Thanks for the report. The offending commit is b821eaa572fd737faaf6928ba046e571526c36c6 Proposed (and tested) fix is below. If you could test and confirm I would appreciate it. Thanks, NeilBrown diff --git a/drivers/md/md.c b/drivers/md/md.c index 46b3a04..4edcda8 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -5895,6 +5895,7 @@ static int md_open(struct block_device *bdev, fmode_t mode) atomic_inc(&mddev->openers); mutex_unlock(&mddev->open_mutex); + check_disk_size_change(mddev->gendisk, bdev); out: return err; }
I just finished a bisect (a nice and straightforward testing one, for once =:^) and yes, it's that commit. I'll test the patch shortly. BTW, enjoyed your kernel design patterns series on LWN, even if I am more sysadmin than coder! =:^) Duncan
Patch confirmed to work. =:^) Thanks, Duncan
Handled-By : Neil Brown <neilb@suse.de> Patch : https://bugzilla.kernel.org/show_bug.cgi?id=16220#c2
Thanks for testing. Patch should appear in -next by the end of the week and in -linus some time later. Thanks for the encouragement -- I used to be a sysadmin: it provides a useful perspective....
Fixed by commit f3b99be19ded511a1bf05a148276239d9f13eefa .