[OpenAFS-devel] Re: Adding utility to do a volume dump table of contents...
Mitch Collinsworth
mitch@ccmr.cornell.edu
Thu, 9 May 2002 17:37:44 -0400 (EDT)
Hi Marc,
Obviously I've been negligent in sending you our code to look at.
Sorry about that. Just when we thought we were ready to give it out
we found a bug... etc.
I'm sorry to say we wrote tocvol last summer, though we called it list.
But here's the interesting part. We recently started testing our code
on our production AFS servers and found that for large volume sets of
20-30 GB and lots of files, "list" can an inordinate amount of time.
For most of our volume sets it's not too bad, but in our worst case it
continues to run for a few hours after the actual dump has finished.
We've been looking at our code to try to find out why but haven't yet
found an obvious problem. The programmer who did our coding is right
now looking at tocvol to see if he can find any obvious algorithmical
difference, in hopes that you may have solved our problem. :-)
One observation: you said tocvol is based on restorevol. Our list is
based on Ken Hornstein's dumptool, though we modified it to be a one-pass
process so that it could read its input from a pipe.
I have to leave now to get home, but I'll make our code available to
you asap so we can work together on the rest of this. We have pretty
much all the pieces this project needs to get started, but some of them
will probably need some cleaning up or integrating into either OpenAFS
or Amanda in order to make everything work well together.
-Mitch
On Thu, 9 May 2002, Marc Mengel wrote:
> There is a utility (restorevol) in OpenAFS to unpack a vos dump image
> into a file tree, but I wanted something to just give me a listing of
> what files/directories were in the volume, so I hacked up the attached,
> which adds "tocvol" to the OpenAFS tree to do a table of contents of a
> vos dump image.
>
> Why did I want this? I'm working on integrating AFS backups into
> Amanda, and I wanted a table of contents of the volume dump so
> I can have file level backup indexing...
>
> Anyway, it's mostly restorevol with most of its guts replaced with
> a (wimpy, horribly inefficient, but simple) vnode graph.
>
>
>