On Mon, Mar 01, 1999 at 08:12:21PM +0100, Manuel Bouyer wrote:
> There is a solution for this in PR 6705 which adds another pass to
> dump to build a map of nodump inodes.

  Hi Manuel!  Thanks for looking into the problem.
  
  Is the extra pass (equivalent to pass 1, which is very fast)
in my solution too much of a price to pay?  IMHO, the code I
suggested (add a bitmap for dumpable/nondumpable, and some
generic FFS walking functions) is much easier to parse and
maintain than adding new meanings to combinations of the
existing bitmap settings (and doing all the patchup in the
traversal later on).  And as noted below, I _think_ you've got
a bug that I don't.  :)
  
> I've tested these change on 2 machines here, they seem to do the rigth thing.

  If you haven't already, you can try out the regression tests I
submitted in PR 6706.  They create a bunch of files in /tmp, and
then do dump estimates, some with nodump set on directories and
files, some with -h0 vs. -h9, and compare the resulting
estimates with the hard-coded ``correct'' estimates.  It could
use some improvement, but it is at least a start.

  When I apply your patches to -current dump, your version
doesn't pass the second test -- a dump of ~120K worth of files
takes up 1.5M, instead of the proper 256K (The excess 130K of
space is dump overhead, I think).  The _contents_ of a
restore are correct, but the dump itself appears to include data
blocks (including blocks for the directory "indirblk", which was
not dumped) that are not referenced by any of the dumped
inodes, apparently.

  If the misbehavior doesn't occur for you on 1.3.3, then it
could be that I flubbed one of the patches when porting your
patches to -current.  I'll be glad to help you track this down,
or provide more detailed info (script output from the regression
test, etc.) if you would like.

  Brian Grayson