backup through the fs (was: Re: Summary of Re: Experiences with 4D/2xx as timesharing systems?)

[jim frost]

>In article <8904131500.AA20088 at adt.uucp> adt!madd at bu-it.bu.edu (jim frost) writes:
>>It is possible (even pretty easy) to build a very
>>good, very reliable backup program which works through the filesystem.
>
>Restoring access times properly is needed (without an additional system call
>and losing the ctime information).

When doing a lot of i/o you just don't loose very bad doing the system
call, especially since you're guaranteed that the inode is in memory.
I don't consider the loss of ctime to be such a tragedy, after all
your restore did technically change the status of the file.

>Dealing with files with holes is also
>mildly tricky (you do want restores of a dumped fs to fit back :-).

Here I have to agree with you, but it's pretty easy to build a program
which not only handles the holes, but creates new holes where they
didn't exist before so your restore is smaller than the original but
still perfectly intact.

>But most
>of all, I don't think incurring the overhead of going through the file system
>is justifiable once you have large amounts of disk space.

If you don't go through the filesystem, you have to build most of the
filesystem code into the dump program.  Most likely you're not going
to go to the effort to streamline accesses as nicely as the filesystem
does (just how much effort do you want to put into your dump,
anyway?), so you're likely to loose anyway.  If you're really looking
for performance, you can take advantage of parallelism to collect the
disk information while waiting for the tape portion of the program to
complete; almost all of the time spent by dump is waiting for the
tape.  This technique has been used on (at least) non-UNIX systems and
resulted in very high throughput even with FS/OS overhead, although
the throughput was lower than if the same technique were used on the
raw filesystem.

jim frost
madd at bu-it.bu.edu