Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.wizards Subject: Re: Why is restore so slow? Message-ID: <10561@dog.ee.lbl.gov> Date: 4 Mar 91 12:42:01 GMT References: <50235@olivea.atc.olivetti.com> <1013@eplunix.UUCP> <480@appserv.Eng.Sun.COM> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 18 X-Local-Date: Mon, 4 Mar 91 04:42:01 PST 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, 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?). (Funny to hear someone from Sun arguing for Unix FS semantics :-) ) Seriously, `synchronous' is more restrictive than necessary. Directory operations must be ordered. They need not be complete by the time the call returns. If they are properly ordered, the inode will exist before the directory entry, and the directory entry will exist before the first file block appears, so that fsync() will guarantee that the file exists and is in permanent storage. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov