Good day. I set up a Woody box recently with RAID-1.
I have two partitions: # df -kl Filesystem 1k-blocks Used Available Use% Mounted on /dev/md1 7740312 981864 6365264 14% / /dev/md0 23239 2921 19118 14% /boot # cat /proc/mdstat Personalities : [raid1] read_ahead 1024 sectors md0 : active raid1 sdb1[1] sda1[0] 24000 blocks [2/2] [UU] md1 : active raid1 sdb3[0] sda3[1] 7863744 blocks [2/2] [UU] unused devices: <none> # It took me awhile to get this up and working but I finally figured it out - mostly working from /usr/share/doc/HOWTO/en-txt/Boot+Root+Raid+LILO.gz and /usr/share/doc/HOWTO/en-txt/Software-RAID-HOWTO.gz and a comment or two gleaned from this list. There were/are no problems until I tried to backup these filesystems. /dev/md0 backs up fine. However, the first time that I tried to back up /dev/md1, I got this: DUMP: Date of this level 0 dump: Thu Feb 21 08:11:46 2002 DUMP: Dumping /dev/md1 (/) to standard output DUMP: Added inode 7 to exclude list (resize inode) DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 463351 tape blocks. DUMP: Volume 1 started with block 1 at: Thu Feb 21 08:11:57 2002 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: bread: lseek fails DUMP: bread: lseek fails DUMP: bread: lseek fails [this line above repeats THOUSANDS of times...] DUMP: Volume 1 completed at: Thu Feb 21 08:13:29 2002 DUMP: Volume 1 532410 tape blocks (519.93MB) DUMP: Volume 1 took 0:01:32 DUMP: Volume 1 transfer rate: 5787 kB/s DUMP: 532410 tape blocks (519.93MB) DUMP: finished in 92 seconds, throughput 5787 kBytes/sec DUMP: Date of this level 0 dump: Thu Feb 21 08:11:46 2002 DUMP: Date this dump completed: Thu Feb 21 08:13:29 2002 DUMP: Average transfer rate: 5787 kB/s DUMP: DUMP IS DONE So it appears that the dump worked but only with thousands of error messages. I decided to get dump from unstable and used that. *THEN* I get some form of this error: DUMP: Date of this level 0 dump: Thu Feb 28 09:54:27 2002 DUMP: Dumping /dev/md1 (/) to /tmp/dump_0_root DUMP: Added inode 7 to exclude list (resize inode) DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 450993 tape blocks. DUMP: Volume 1 started with block 1 at: Thu Feb 28 09:54:38 2002 DUMP: dumping (Pass III) [directories] /dev/md1: EXT2 directory corrupted while converting directory #65573 DUMP: error reading command pipe: Connection reset by peer DUMP: error reading command pipe: Connection reset by peer The first time that I got this I thought that there must be some hardware error. I searched and found the inode referred to by dump (which happened to be in /tmp) and removed the directory. I re-ran the dump (still using unstable's dump) and got the same error but a different inode (something under /var/run... :-( ). So my compatriot suggested fsck'ing the live filesystem. That was not too bright a move and after i reinstalled everything I was ready to start trying dump again. Actually, at this point I was pretty disgusted with the whole thing and put on RedHat 7.2, making RAID filesystems from the pretty install GUI. That worked fine (and was quite easy). *AND* I could dump /dev/md1 from RedHat with no problem. dump didn't even hiccup. Darn. *BUT* I really want to stick with Debian. So I re-installed Woody again (a glutton for punishment, apparently). I tried using the dump from RedHat 7.2 and from Mandrake 8.0 and get similar results. I also tried dump'ing either "/" or "/dev/md1". That didn't seem to make any difference. I tried upgrading to unstable's raidtools2, e2fsprogs, libc, anything related to dump. Each time the backup failed in the same way. For grins, I tried backing up /dev/sda3 instead of /dev/md1 and that works! Now why is that?!? Can someone please explain this to me or help me figure out (a) if there is a problem with my system or (b) how to work around this? I can live with backing up /dev/sda3 but why should I have to? Am I causing myself some unknown future headaches? So many questions. So little time. Thanks for any help! - Bill +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Bill Benedetto <[EMAIL PROTECTED]> The Goodyear Tire & Rubber Co. I don't speak for Goodyear and they don't speak for me. We're both happy.