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

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
	agrier@poofygoof.com
Subject: Re: bin/35966: dump reports negative time estimates and writes too much data
Date: Mon, 12 Mar 2007 20:34:28 +0100

 On Mon, Mar 12, 2007 at 03:15:10AM +0000, Aaron J. Grier wrote:
 >  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?
 
 You can look for an unreasonably large file in the dump.
 I guess the following could happend:
 file a has one indirect block.
 - in pass 1 dump makes a list of inodes to be dumped
 - a is removed, or trucated.
 - the indirect block is reallocated for a new file, or a file that has
 - been extended.
 - in pass 4 dump get's a inode, fron it gets the list of blocks to write.
   The inode points to an indirect block which now is a data block. When
   interpreting it as an indirect block it gets much more blocks than
   there was in 'a' initially. 
 
 >  [...]
 >  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.
 
 Yes, most probably.
 
 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --