Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!rutgers!cbmvax!grr From: grr@cbmvax.commodore.com (George Robbins) Newsgroups: comp.unix.wizards Subject: Re: Why is restore so slow? Message-ID: <19576@cbmvax.commodore.com> Date: 6 Mar 91 20:28:29 GMT References: <50235@olivea.atc.olivetti.com> <1013@eplunix.UUCP> <480@appserv.Eng.Sun.COM> <6511@stpstn.UUCP> <485@appserv.Eng.Sun.COM> Reply-To: grr@cbmvax.commodore.com (George Robbins) Organization: Commodore, West Chester, PA Lines: 35 In article <485@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM (Larry McVoy) writes: > 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. 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@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)