On Sat, Oct 27, 2007 at 08:26:00PM -0400, Doug Ledford wrote:
On Sat, 2007-10-27 at 00:30 +0200, Gabor Gombas wrote:
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
> In fact, no you can't. I know, because I've created a device that had
> both but wasn't a raid device. And it's matching partner still existed
> too. What you are talking about would have misrecognized this
> situation, guaranteed.
Maybe we need a 2.0 superblock that contains the physical size of every
component, not just the logical size that is used for RAID. That way if
the size read from the superblock does not match the size of the device,
you know that this device should be ignored.
In my case that wouldn't have helped. What actually happened was I
create a two disk raid1 device using whole devices and a version 1.0
superblock. I know a version 1.1 wouldn't work because it would be
where the boot sector needed to be, and wasn't sure if a 1.2 would work
either. Then I tried to make the whole disk raid device a partitioned
device. This obviously put a partition table right where the BIOS and
the kernel would look for it whether the raid was up or not. I also
the only reason i can think for the above setup not working is udev
mucking with your device too early.
tried doing an lvm setup to split the raid up into chunks and that
didn't work either. So, then I redid the partition table and created
individual raid devices from the partitions. But, I didn't think to
zero the old whole disk superblock. When I made the individual raid
devices, I used all 1.1 superblocks. So, when it was all said and done,
I had a bunch of partitions that looked like a valid set of partitions
for the whole disk raid device and a whole disk raid superblock, but I
also had superblocks in each partition with their own bitmaps and so on.
OK
It was only because I wasn't using mdadm in the initrd and specifying
uuids that it found the right devices to start and ignored the whole
disk devices. But, when I later made some more devices and went to
update the mdadm.conf file using mdadm -Eb, it found the devices and
added it to the mdadm.conf. If I hadn't checked it before remaking my
initrd, it would have hosed the system. And it would have passed all
the above is not clear to me, afair redhat initrd still uses
raidautorun, which iirc does not works with recent superblocks,
so you used uuids on kernel command line?
or you use something else for initrd?
why would remaking the initrd break it?
the tests you can throw at it. Quite simply, there is no way to tell
the difference between those two situations with 100% certainty. Mdadm
tries to be smart and start the newest devices, but Luca's original
suggestion of skip the partition scanning in the kernel and figure it
out from user space would not have shown mdadm the new devices and would
have gotten it wrong every time.
yes, in this particular case it would have, congratulation you found a new
creative way of shooting yourself in the feet.
maybe mdadm should do checks when creating a device to prevent this kind
of mistakes.
i.e.
if creating an array on a partition, check the whole device for a
superblock and refuse in case it finds one
if creating an array on a whole device that has a partition table,
either require --force, or check for superblocks in every possible
partition.
L.
--
Luca Berra -- bluca@xxxxxxxxxx
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
