The following reply was made to PR bin/35966; it has been noted by GNATS.

From: "Aaron J. Grier" <agrier@poofygoof.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/35966: dump reports negative time estimates and writes too much data
Date: Sun, 11 Mar 2007 20:11:22 -0700

 On Sun, Mar 11, 2007 at 09:10:05PM +0000, Manuel Bouyer wrote:
 >  > let me get this straight; the dump estimated 10243859 blocks, yet
 >  > wrote 169098219 blocks?  how is that possible?
 >  
 >  This can easily happen if you dump a live filesystem. Was there some
 >  write activity to this partition while you ran the dump ?
 
 possibly.  logging activity is to /var (which backs up fine), and I've
 been running with this configuration for a few months now.  it could be
 a race condition that simply hasn't been previously tripped.
 
 is it possible for me to find out what caused this since I have the dump
 on tape?
 
 some more (possibly useless) information:
 
 the previous' night's backup died with the following:
 
 DUMP: Found /dev/rwd0f on /usr in /etc/fstab
 DUMP: Date of this level 0 dump: Wed Mar  7 00:34:24 2007
 DUMP: Date of last level 0 dump: the epoch
 DUMP: Dumping /dev/rwd0f (/usr) to standard output
 DUMP: Label: none
 DUMP: mapping (Pass I) [regular files]
 DUMP: mapping (Pass II) [directories]
 DUMP: estimated 10242447 tape blocks.
 DUMP: Volume 1 started at: Wed Mar  7 00:35:18 2007
 DUMP: dumping (Pass III) [directories]
 DUMP: dumping (Pass IV) [regular files]
 DUMP: 4.52% done, finished in 1:45
 DUMP: Child 28415 returns LOB status 213
 
 I suspected disk trouble.  "dd if=/dev/rwd0f of=/dev/null bs=1m"
 produced no errors.  smartctl showed the drive had no recovered read
 errors.  I took the machine down to single user, and forced a fsck of
 the partition, also with no errors.
 
 the following night I got the 16x dump as already filed.
 
 I assume using a snapshot (with -X) would avoid this issue; I would just
 like to know for sure what is going on before I proceed.