Why is restore so slow?

[Stuart Levy]

In article <2880 at redstar.cs.qmw.ac.uk> liam at cs.qmw.ac.uk (William Roberts;) writes:
>In <50235 at olivea.atc.olivetti.com> jerry at olivey.olivetti.com (Jerry Aguirre) 
>writes:
>
>>Has anyone done any evaluations of why there is such an extreem
>>difference in speed?  Granted that creating files involves more overhead
>>than dumping them restore still seems very slow.  As restore operates on
>>the mounted file system it has the advantage of accessing a buffered
>>file system with write behind.

Aha, that's the problem.  On BSD-derived systems (e.g. Suns) at least,
there are lots of synchronous operations done as files are created,
space allocated, and directories modified.  The point is to make the
filesystem more robust -- a system crash in mid-update doesn't leave corrupted
directories, or blocks in the free list that also point into a file, or etc.
Write-behind still applies to file *data*, but the restore bottleneck is
in creating all those files.

A few years ago I hacked the BSD filesystem code so, when a mode was set,
most of those synchronous bwrite() calls would get changed to delayed
bdwrite()s.  It helped -- restore performance rose by about a factor of 2,
still much slower than dump but more nearly tolerable.  Of course this was
unsafe, and the mode was only enabled when we were restoring a wrecked
filesystem.

	Stuart Levy, Geometry Group, University of Minnesota
	slevy at geom.umn.edu