I had occasino to want to dump some stuff from a biggish filesystem
("928G" according to df -h) to tape.  So I ran dump:

# dump -0 -a -b 1000 -e -f /dev/nrst0 -t /dev/rld2a

This cogitated ("mapping (Pass I) [regular files]") for about two and a
half minutes, then very quickly (<1s elapsed) spit out a few more
lines, ending with

  [15:16:01 EST] DUMP: dumping (Pass III) [directories]
  DUMP: master/slave protocol botched.
  [15:16:01 EST] DUMP: The ENTIRE dump is aborted.

Pulling the -b value down to 256 seems to make it work (or at least not
fall over abruptly), but is this really the bug in dump it appears to
be, or a case of pilot error?

In case it matters, here are the first 20 lines of dumpfs output for
the filesystem.

endian  little-endian
magic   11954 (UFS1)    time    Sun Jan 15 11:14:27 2006
superblock location     8192    id      [ 4383a64c 19a784b7 ]
cylgrp  dynamic inodes  4.4BSD  sblock  FFSv2   fslevel 4
nbfree  6611913 ndir    3511    nifree  30251315        nffree  6154
ncg     1171    size    244106744       blocks  243141827
bsize   32768   shift   15      mask    0xffff8000
fsize   4096    shift   12      mask    0xfffff000
frag    8       shift   3       fsbtodb 3
bpg     26058   fpg     208464  ipg     25856
minfree 5%      optim   time    maxcontig 2     maxbpg  8192
symlinklen 60   contigsumsize 2
maxfilesize 0x004002001005ffff
nindir  8192    inopb   256
avgfilesize 16384       avgfpdir 64
sblkno  8       cblkno  16      iblkno  24      dblkno  832
sbsize  4096    cgsize  32768
csaddr  832     cssize  20480
cgrotor 0       fmod    0       ronly   0       clean   0x01
flags   none

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B