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
--