On Wed, 16 Dec 1998, Thilo Herrmann wrote:
> compiling the tools after compiling & booting the kernel in
> /usr/src/linux) gave a minor problem.
>
> mkpv.c: BLKGETSIZE undefined.
> After adding
> #include <linux/fs.h>
> all went well.
i guess your system is not glibc based. Including Linux kernel headers is
now considered pretty unsafe.
> minor inconvenience with raidstop:
>
> raidstart -a
> works, but
> raidstop -a
> gives "nothing to do",
> raidstop /dev/md0
> works
(ok, i'll fix this. I dont use raidstop anymore because the kernel always
stops all RAID arrays before rebooting.)
> no (automatic?) reconstruction of degraded array:
>
> building the raid, mke2fs & mount went well.
>
> I waited until the raid5-construct was complete, then did a little test:
>
> umount
> raidstop
> badblocks -w /dev/hde1 (scrambling first raid5 disk with 0xaaaaaaaa)
oops, this just destroyed the RAID superblock on that disk ...
> raidstart /dev/md0 worked (after reordering /dev/raidtab), but the
because hde1 had no RAID info at all. If you use autostart then the array
will be started even in this case. raidstart should probably iterate
through all listed drives in the raidtab, but i think it's better to
conservatively say 'oops, abort'.
> kernel didnīt want to reconstruct /dev/hde1 (var/log/messages below).
> The disk is marked as down in /proc/mdstat:
> _UUU
it's a failed disk! You have just destroyed it's superblock.
> My question is: How can I convince the kernel to rebuild /dev/hde1?
> Did I miss an additional command that accomplishes this (a new mdop)?
> Should I reboot the system?
you can use raidhotremove/raidhotadd to add a new disk. (can be the same
'failed' disk in the simulation case)
> The problem is that I want to be absolutely sure that I can restore an
> array to a non-degraded state.
yep, try:
raidhotadd /dev/md0 /dev/hde1
(there was one bug displayed in the logs, i've fixed this in my tree
already. a reboot would have fixed this bug, and it's nonfatal.)
-- mingo
