Why is restore so slow?

[xtdn at levels.sait.edu.au]

OK, so I've seen lot's of postings suggesting that the reason restore is so
slow (compared to dump) is because reliability is more important than
efficiency.  But that argument is just a nonsense.  And it completely fails
to explain why dump (which, after all, needs to be just as reliable) is so
much faster than restore.

Now I don't know why there's such a difference in performance but I do
suspect that perhaps it's deliberate.  I think it's a reasonable assumption
that (sensible) people do backups much more often than they do restores.
Given that, I also think it makes good sense to optimise dump, even to the
point that restore suffers in performance.

One such optimisation could be to write the raw disk to tape (actually you'd
only dump those blocks that contain data that you want backed up, but the
point is that you'd be reading from the raw disk).  This would be quite fast
because you wouldn't be opening each file (which takes time), or reading the
file sequentially - see how much disk head movement you avoid?  Now such a
tape would consist of a number of chunks, each chunk detailing the file, the
file offset, and the data to write at that offset.  The restore process then
becomes a matter of reading the next chunk, opening and seeking the file, and
then writing the data.  All that head movement, opening files, seeking to the
right spot, and later, closing files, would certainly slow down the process.

I already said that I don't know how dump/restore works, but I would almost
be willing to bet that it's something like the scheme I just outlined.  Maybe
someone who does know could tell us what really happens?


David Newall, who no longer works       Phone:  +61 8 344 2008
for SA Institute of Technology          E-mail: xtdn at lux.sait.edu.au
                "Life is uncertain:  Eat dessert first"