freebsd stable - Jan 2005 - dump dumping core

With RELENG_5 from yesterday, as well from a week or so ago I'm finding 
that dump is failing.  Must admit, this is the first time I've tried to 
run a backup since migrating from RELENG_4 to RELENG_5.

fsck -f / marks the file system as clean.

Any ideas?

root@shrewd# dump -0a -b 512 -f - / > /dev/null
   DUMP: WARNING: should use -L when dumping live read-write filesystems!
   DUMP: Date of this level 0 dump: Mon Jan  3 21:38:32 2005
   DUMP: Date of last level 0 dump: the epoch
   DUMP: Dumping /dev/ad0s1a (/) to standard output
   DUMP: mapping (Pass I) [regular files]
   DUMP: mapping (Pass II) [directories]
   DUMP: estimated 21084554 tape blocks.
   DUMP: 0.00% done, finished in 0:00 at Mon Jan  3 21:38:44 2005
   DUMP: dumping (Pass III) [directories]
   DUMP: SIGSEGV: ABORTING!
   DUMP: SIGSEGV: ABORTING!
   DUMP: SIGSEGV: ABORTING!
   DUMP: SIGSEGV: ABORTING!
   DUMP: SIGSEGV: ABORTING!
Segmentation fault (core dumped)

root@shrewd# gdb /sbin/dump -c dump.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions. Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details. This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `dump'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x2814a687 in memcpy () from /lib/libc.so.5
(gdb) bt
#0  0x2814a687 in memcpy () from /lib/libc.so.5
#1  0x080506a7 in bread (blkno=1001, buf=0x82b4000 "", size=0)
     at /usr/src/sbin/dump/traverse.c:785
#2  0x0804e406 in doslave (cmd=4, slave_number=0)
     at /usr/src/sbin/dump/tape.c:787
#3  0x0804e235 in enslave () at /usr/src/sbin/dump/tape.c:725
#4  0x0804df6f in startnewtape (top=1) at /usr/src/sbin/dump/tape.c:630
#5  0x0804b309 in main (argc=0, argv=0xbfbfec48)
     at /usr/src/sbin/dump/main.c:503
(gdb) up
#1  0x080506a7 in bread (blkno=1001, buf=0x82b4000 "", size=0)
     at /usr/src/sbin/dump/traverse.c:785
785                             memcpy(&buf[xfer], tmpbuf, resid);
(gdb) print resid
$1 = -512

Cheers,
-- 
Mark A. R. Knight                               finger: markk@knigma.org
Tel: +44 7973 410732                            http://www.knigma.org/

In message <IB1XwOsi1b2BFweI@lap.knigma.org>, Mark Knight 
<markk@knigma.org> writes
>With RELENG_5 from yesterday, as well from a week or so ago I'm finding 
>that dump is failing.  Must admit, this is the first time I've tried to 
>run a backup since migrating from RELENG_4 to RELENG_5.
>
>fsck -f / marks the file system as clean.
>
>Any ideas?
>
>root@shrewd# dump -0a -b 512 -f - / > /dev/null
The -b 512 (or other large values), seems to be the key to making it 
crash (on various inodes).  Sometimes the error is "master/slave 
protocol botched" instead.

Until I find the cause, the workaround of "don't do that then"
seems
appropriate.  At least it wasn't fs corruption ;)
-- 
Mark A. R. Knight                               finger: markk@knigma.org
Tel: +44 7973 410732                            http://www.knigma.org/