> if you hotadd the (repaired or replaced) /dev/sda1 again you'll have
> raid-disk1 /dev/sda3
> raid-disk2 /dev/sda2
> spare /dev/sda1
So "Yes, you do have to manually edit /etc/raidtab to keep in sync". Ta.
> the patch to raidtools + kernel
Which patch to raidtools ? (I have tried raidtools-19990309-0.90)
% gunzip < ../raidtools-19990309-0.90.tar.gz | egrep 'strcmp.par|failed-dis'
if (strcmp(par, "raiddev") == 0) {
if (strcmp(par, "raid-level") == 0) {
} else if (strcmp(par, "nr-raid-disks") == 0) {
} else if (strcmp(par, "persistent-superblock") == 0) {
} else if (strcmp(par, "nr-spare-disks") == 0) {
} else if (strcmp(par, "parity-algorithm") == 0) {
} else if (strcmp(par, "chunk-size") == 0) {
} else if (strcmp(par, "device") == 0) {
} else if (strcmp(par, "raid-disk") == 0) {
} else if (strcmp(par, "spare-disk") == 0) {
} else if (strcmp(par, "parity-disk") == 0) {
%
> no, just mke2fs the raid device and copy the stuff over using cp -aR (or
> tar or ..)
Sure -- you made it sound so complicated that I assumed it was more subtle
> raidhotadd will only work for raid types supporting redundancy, meaning 1,4
> and 5.
Ta -- finger trouble -- I meant /dev/md1 ... :-(
Now I get:
md1:active raid1 hda9[1] hda8[0] 3904 blocks [1/1] [U] resync=0% finish=64.6min
although the logs show:
Mar 18 16:18:35 dean kernel: md: updating md1 RAID superblock on device
Mar 18 16:18:35 dean kernel: hda9 [events: 00000002](write) hda9's sb offset: 3904
Mar 18 16:18:35 dean kernel: hda8 [events: 00000002](write) hda8's sb offset: 3904
Mar 18 16:18:35 dean kernel: .
Mar 18 16:18:35 dean kernel: md: recovery thread got woken up ...
Mar 18 16:18:35 dean kernel: md: recovery thread finished ...
> you do, it's jst not documented :-) Just try mkraid --debug /dev/md0
I had raidtools-19981105-0.90 which does not have it :-(
> this just reads the configuration and prints it to syslog.
To me "mkraid --debug /dev/md0" means "make /dev/md0, and debug what you do".
There should be a new name (e.g. "raidinfo") which can take the --debug flag,
and which does *NOT* demand a device name ....
I would be quite happy to run "raidinfo --debug" ....
How about the ability to write into the /proc/ FS to tell the md code to
1) dump the current info to syslog
2) autodetect (new) devices
etc ... and maybe a file that allows direct reading of what "--debug" sends to
syslog ...
SO: I take it that nobody else has problems with 2.2.3 + raid0145-19990309-2.2.3
failing during LILO uncompress with "Out of memory" ? :-((
