steve@polyslo.CalPoly.EDU (Steve DeJarnett) (05/26/89)
Can anyone in netland give any good reason why restore takes as much as 4x longer to run than dump does on the same filesystem?? Let me explain a little more clearly the problem. We did a level 0 dump of a disk (all of the files) about 2 weeks before we lost it in a crash. That dump took about 1 hour and 5 minutes to complete (Fuji Eagle -- f partition). After installing a new disk, formatting, and newfs-ing it, we ran restore onto it. The restore took over 4.0 hours to complete!!! Maybe I'm expecting way too much, but it seems to me (and I'm sure I'm missing some of the details here) that dump and restore should be mostly the same program, with the only difference being the reversing of the system calls (write instead of read). I know that it must create all of the directories in restore, which will take quite a while, but 4x as long doesn't seem quite right to me. The restore ran on an unloaded machine (it was in single user mode). The dump also ran on an unloaded machine. Anyone have an explaination for this?? I haven't run similar tests (thank God) on any of our other systems, so I don't know if this is par for the course, or if it's extraordinary. Any comments?? Am I missing something glaringly obvious that easily explains this??? Thanks, ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | -------------------------------------------------------------------------------
karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) (05/26/89)
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
chris@MIMSY.UMD.EDU (Chris Torek) (05/26/89)
In article <11218@polyslo.CalPoly.EDU> unmvax!polyslo!steve@ucbvax.Berkeley.EDU (Steve DeJarnett) writes: >Can anyone in netland give any good reason why restore takes as >much as 4x longer to run than dump does on the same filesystem?? This is typical of most 4BSD systems. Essentially, the reason is that restore uses the file system in a straightforward manner, and dump reads the raw device in a much-optimised manner. Since full dumps are done much more often than full restores, this seems quite reasonable. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris