Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!dinosaur.cis.ohio-state.edu!karl From: karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) Newsgroups: comp.sys.pyramid Subject: Re: dump/restore in OSx 4.4 Message-ID: Date: 26 May 89 02:58:26 GMT References: <11218@polyslo.CalPoly.EDU> Sender: news@tut.cis.ohio-state.edu Distribution: na Organization: OSU Lines: 26 In-reply-to: steve@polyslo.CalPoly.EDU's message of 25 May 89 22:33:18 GMT 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