Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!topaz!harvard!cmcl2!philabs!nyit!rick
From: rick@nyit.UUCP (Rick Ace)
Newsgroups: net.decus,net.unix,net.usenix
Subject: Re: Favorite operating systems query
Message-ID: <243@nyit.UUCP>
Date: Thu, 19-Jun-86 10:54:50 EDT
Article-I.D.: nyit.243
Posted: Thu Jun 19 10:54:50 1986
Date-Received: Sat, 21-Jun-86 10:24:33 EDT
References: <339@valid.UUCP> <452@geowhiz.UUCP> <1747@utah-gr.UUCP>
Distribution: net
Organization: NYIT Computer Graphics Lab., Old Westbury, N.Y.
Lines: 45
Xref: watmath net.decus:341 net.unix:8290 net.usenix:597

> >6) File system.  Why, oh, why, must the Unix file system be so fragile?  VMS
> >   never loses your files.
> I can count on the fingers of one foot the number of times I have lost a
> file due to "file system fragility" in the last 5 years on a Unix
> system.  This "myth" is just that, and it's time to lay it to rest.
>
> ...
>
> =Spencer   ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)

Well, almost a myth.  UNIX filesystem implementations (even the touted
one in 4.2bsd) trade off filesystem integrity for speed in places
where other operating systems give you the guarantee that your data
is safe.  For example, when you issue the CLOSF JSYS to close a file in
TOPS-20, you are assured that your data is safely out on the disk when
the JSYS returns.  The close(2) syscall, however, does *not* give you that
guarantee, and I have gotten screwed at least once like this:

	Edit a file with my text editor
	Write the file out and exit editor
	Power failure (or other abrupt termination of UNIX) before next sync
	Reboot, fsck finds my file and claims it has no data blocks
	 (the data was floating in the buffer cache when UNIX went down)

Even more infuriating:  neither the pre-edit nor the post-edit copy
of the file remained after the crash, because the creat() syscall
issued by the editor when writing out the file truncated the inode!

I have since enhanced that editor to fsync() the file before close()ing
it, but many people would argue that the operating system should take
more responsibility for ensuring the safety of users' files.  And what
does one do on a UNIX variant without fsync()?  The sync() syscall
isn't really acceptable because 1) there is no way to limit the overhead
to just one specific file, and 2) the return of sync() to the user program
means only that the flush-to-disk operation has begun (i.e., you can't
determine when it has completed).

-----
Rick Ace
Computer Graphics Laboratory
New York Institute of Technology
Old Westbury, NY  11568
(516) 686-7644

{decvax,seismo}!philabs!nyit!rick