Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!sun-barr!newstop!exodus!appserv!slovax.Eng.Sun.COM!lm From: lm@slovax.Eng.Sun.COM (Larry McVoy) Newsgroups: comp.unix.wizards Subject: Re: Why is restore so slow? Message-ID: <485@appserv.Eng.Sun.COM> Date: 6 Mar 91 08:59:23 GMT References: <50235@olivea.atc.olivetti.com> <1013@eplunix.UUCP> <480@appserv.Eng.Sun.COM> <6511@stpstn.UUCP> Sender: news@appserv.Eng.Sun.COM Reply-To: lm@slovax.Eng.Sun.COM (Larry McVoy) Organization: Sun Microsystems, Mt. View, CA. Lines: 17 In article <6511@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: >In article <480@appserv.Eng.Sun.COM> lm@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. --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com