On Mar 1, Brian C. Grayson wrote
>   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?

The directory tree is already walked in pass 2. Adding a pass to propagate
nodump seems just redontant to me. And the code you added as a lot of
redoundant functionalities with the one used by pass 2. It's when trying
to merge these code I would that an extra pass was not needed.

> 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.  :)

Well, I not sure leaving the nodump files out of the used inode map
is such a big hack: these files have to be ignored by dump, just as
unused inodes.

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

I looked at this, but it had a problem: if /tmp is MFS, you loose.
Also, I found the size of the dump depends on how the filesystem is
setup and how many files are on it. I changed this to use a fresh
filesystem on a vnd device, which give more reliable results.
Now I want to use this for a whole filesystem suite test (dump, fsck,
mount/read/write). 

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

Well, I got this one using your regress test: for directories with more
than 1 data block, only the first block was properly handled.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--