http://bugzilla.novell.com/show_bug.cgi?id=567652 http://bugzilla.novell.com/show_bug.cgi?id=567652#c5 Petr Uzel <puzel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO CC| |mmarek@novell.com, | |teheo@novell.com Info Provider| |teheo@novell.com --- Comment #5 from Petr Uzel <puzel@novell.com> 2010-01-07 15:24:05 UTC --- (In reply to comment #4)
/sys/block/mdX/range is 1 and ext_range is 256.
Parted up to 1.9.0 uses /sys/block/DEV/range to determine the highest possible partition number that might exist on DEV. Since it is 1 in your case, parted will not inform kernel about any partition except the first one. As far as I understand, /sys/block/DEV/range represents maximum number of partitions DEV can contain. Tejun: is this correct? Or should ext_range be also consulted when looking for highest possible partition number on given device? If I create the array like in comment #2, then range==64.
I suppose the manpage of mdadm is outdated with kernel 2.6.28 where the kernel simply names the devices mdXpY. I don't know, but as I wrote above, it behaves differently when created with /dev/dm_dX name wrt to range attribute. Adding mdadm maintainer to CC:
The problem isn't that device nodes or entries in /proc/partitions are missing but that the entires in /proc/partitions are not updated after resizing the partiton with parted. Rereading the partition table with blockdev updates /proc/partitions.
I get this. With device whose range==1, kernel won't be informed about any changes of partitions with no.>=2. So either 1) MD device with range==1 isn't supposed to be partitioned 2) there is a bug in MD causing range==1 3) there is a bug parted => the algorithm for determining largest partition number for a device has to be fixed Apart from that, there still might be some parted/kernel/udev/hal timing issues (the fix for bug #539521 doesn't seem to work in all cases), but without fixing the range thing, this cannot work. I'm going to investigate further. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.