Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!appserv!slovax!lm From: lm@slovax.Berkeley.EDU (Larry McVoy) Newsgroups: comp.unix.wizards Subject: Re: Why is restore so slow? Message-ID: <480@appserv.Eng.Sun.COM> Date: 4 Mar 91 01:02:08 GMT References: <50235@olivea.atc.olivetti.com> <1013@eplunix.UUCP> Sender: news@appserv.Eng.Sun.COM Reply-To: lm@Eng.Sun.COM Organization: Sun Microsystems, Inc. Lines: 17 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, something that occurs quite often in restore :-), is synchronous. It has to be, those are the semantics of a Unix file system (can you say lock files?). It actually has to be atomic and completed when the system call returns to the user, the fact that it is synchronous is an implementation issue that has been much discussed in comp.arch; I took the point of view that it was a "good thing" and somebody from Japan took the point of view that it was "too slow". Before everyone starts complaining, think back to the days that you had to repair file systems with fsdb (remember that? If not, be quiet). The correct fix, in my opinion, is hardware, not software. Use NVRAM and reclaim the directory pages from that. The semantics remain and you get the performance back. --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com