On Sun, Oct 28, 2007 at 01:47:55PM -0400, Doug Ledford wrote:
On Sun, 2007-10-28 at 15:13 +0100, Luca Berra wrote:
On Sat, Oct 27, 2007 at 08:26:00PM -0400, Doug Ledford wrote:
>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,
RHEL does, but this is on a personal machine I installed Fedora an and
latest Fedora has a mkinitrd that installs mdadm and mdadm.conf and
starts the needed devices using the UUID. My first sentence above
should have read that I *was* using mdadm.
ah, ok i should look again at fedora's mkinitrd, last one i checked was
6.0.9-1 and i see mdadm was added in 6.0.9-2
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?
Remaking the initrd installs the new mdadm.conf file, which would have
then contained the whole disk devices and it's UUID. There in would
have been the problem.
yes, i read the patch, i don't like that code, as i don't like most of
what has been put in mkinitrd from 5.0 onward.
Imho the correct thing here would not have been copying the existing
mdadm.conf but generating a safe one from output of mdadm -D (note -D,
not -E)
>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.
Creative, not so much. I just backed out of what I started and tried
something else. Lots of people do that.
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.
What happens if you add the partition table *after* you make the whole
disk device and there are stale superblocks in the partitions? This
still isn't infallible.
It depends on what you do with that partitioned device *after* having
created the partition table.
- If you try again to run mdadm on it (and the above is implemented it
would fail, and you will be given a chance to wipe the stale sb)
- If you don't and use them as plain devices, _and_ leave the line in
mdadm.conf you will suffer a lot of pain. Since the problem is known and
since fdisk/sfdisk/parted already do a lot of checks on the device, this
could be another useful one.
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
