Why is restore so slow?

[George Robbins]

In article <485 at appserv.Eng.Sun.COM> lm at slovax.Eng.Sun.COM (Larry McVoy) writes:
> In article <6511 at stpstn.UUCP> lerman at stpstn.UUCP (Ken Lerman) writes:
> >In article <480 at appserv.Eng.Sun.COM> lm at Eng.Sun.COM writes:
> >>
> >>I believe that a key component to the slowness of restore is the synchronous
> >>nature of directory operations in the Unix file system.  For example, a create,
> >Has anyone out there with the appropriate source done some measurement
> >of where the time goes in restore?  How many reads/writes does it do?
> >How long does each take?  Do those figures seem reasonable? ...etc...
> 
> Well, I didn't want to tip my hand, but someone at Sun actually tried turning
> off the sync writes (dir ops) while restoring a system.  A speed up of 4X
> is what I remember, but I might be a little off.  Your mileage may vary.
> 
> NVRAM in the disk interface is the easy answer, a option to mount is the
> sleazy answer.

I don't see what's easy about NVRAM, it's expensive and still requires some
new software action on restart that unix doesn't do presently.

The mount option isn't sleazy, it just represents putting some options at
a very key point where the "one size fits all" philosophy is getting painful.

I've felt for a long time that options at the mount point for 100% synchronous
writes (for floppies) was pretty obvious, providing a similar option for
non-synchronous operation, for either restores or "don't care" temporary
filesystems seems painless.  I shouldn't mention the never sync option to
confine writes to a rom based filesystem to the buffer pool...

---
A hardware type who gets very bored waiting to restore ~500 MB news paritions.
-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr at cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)