dump/restore in OSx 4.4

[Karl Kleinpaste]

You're missing something "glaringly obvious."  Dump has the advantage
that it does its work via a direct read of the raw disc, sucking in
inodes the hard way and not depending on system call interaction to
figure things out.  This said, you can see that it's possible for dump
to pull in LARGE chunks of disc and then cogitate on them at leisure.

Restore, on the other hand, has no choice but to create filesystem
objects via the usual system call interfaces using creat(2), mknod(2),
mkdir(2), and so forth.  You mount the new filesystem, and tell
restore to go to it.  Now every single file to be recreated takes at
least several system calls, entailing drastic overhead hits as it
executes, e.g., creat(2), write(2), utimes(2) (gotta set that
modification timestamp properly, y'know), and all the related rot.

This is not to say that something couldn't be done about it.  We run a
modified restore here which is fast enough that I can dump an Eagle
`h' partition in 12 minutes, documentable from the last time we lost
our news partition - Paul "gratuitous speed" Placeway of our staff
created a fairly neat hack where 4 simultaneous entities are busy
under a single controlling dump(8).  Similar thoughts can apply to
restore(8) to get better performance out of the tape operation and so
forth, but I don't know of anyone who has put the work into doing such
things.  All that stands in the way is extra time and new code.  If
you're feeling inspired, go to it.

--Karl