Problem with dump'ing of RAID filesystem (somewhat long. sorry.)
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 <bbenedetto@goodyear.com> The Goodyear Tire & Rubber Co.
I don't speak for Goodyear and they don't speak for me. We're both happy.
Reply to: