[ I am no longer on this list, pleast reply to me in person. My apologies if
this is a FAQ. ]
I recently tried to upgrade from linux 2.1.120 with raidtools 0.52beta2 to
2.2.1 with the 1-28 version of raidtools.
I downloaded linux-2.2.1.tar.gz, applied raid0145-19990128-2.2.0 (it works
fine aside from some masking calculation in mmap.c which seems to have been
fixed (or at least changed) in 2.2.1 anyway). I ran ./mkraid --upgrade
/dev/md0 (with the new tools), made a new initial ramdisk/bootdisk with the
new raidtools and restarted. Everything worked ... sort of :-(. The newer
raid code autostarted and ran everything ... but it seemed to calculate a
different total size than the 2.1.120 version (new size == smaller). This
gave e2fsck fits (recorded fs size != block device size) and it yelled
about a large number of free inode count mismatches. After a long e2fsck
the filesystem came up ... but many files (chosen apparently at random, but
sadly including my home directory) showed up as (roughly):
?--------- 0 weimer weimer 0 Feb 3 18:37 weimer
instead of:
drwx------ 25 weimer weimer 4096 Feb 3 18:37 weimer/
Horrified, I shut everything down and rebooted back to 2.1.120. e2fsck
claimed it had to check the filesystem ("filesystem with errors") but
printed out no messages and now everything is back to its previous
condition (no lost files, no apparent permanent damage).
I have one RAID0 array spanning four partitions, two of which are 2 gigs
and two of which are 6 gigs. I'm happy to provide any additional
information about my setup.
Any idea why this is going on? Did I miss some critical step in the upgrade
process? Can someone out there help me to get the newer code up and
running?
-Wes Weimer
[EMAIL PROTECTED]
Personalities : [2 raid0]
read_ahead 128 sectors
md0 : active raid0 hda1 sda1 hdc1 sdc1 16707464 blocks 4096k chunks
md1 : inactive
...
