Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: buffer cache vs. file system reliability
Message-ID: <3031@umcp-cs.UUCP>
Date: Wed, 20-Aug-86 12:42:36 EDT
Article-I.D.: umcp-cs.3031
Posted: Wed Aug 20 12:42:36 1986
Date-Received: Thu, 21-Aug-86 01:47:42 EDT
References: <514@opus.nbires.UUCP> <240@whuxcc.UUCP> <244@desint.UUCP> <792@ho95e.UUCP>
Reply-To: chris@umcp-cs.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 25

>In article <244@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes:
>>This [immediate physical I/O for, e.g., directory writes] is an
>>unfortunate side effect of the file system reliability enhancements
>>that were done for System V (III?).

In article <792@ho95e.UUCP> wcs@ho95e.UUCP (Bill Stewart
1-201-949-0705 ihnp4!ho95c!wcs HO 2G202) asks:
>Is there any way to tell the system "Don't bother syncing /tmp"?

It would be relatively easy to add to the 4.2/4.3BSD file system
a parameter marking any particular file system as `unreliable',
and, based on this, to use delayed writes for all FS operations.
We like reliable /tmp files here, since editor temporaries are
stored there; but after about the fifth full file system restore,
I have been considering at least adding a global flag (set via `adb
-w' on the running kernel) to disable synchronous writes entirely.
If the restore dies for some reason, I am going to restart the
whole thing anyway: so I care not if what I have after the crash
is unsalvageable.  Restores are infrequent enough that any serious
work to speed them is not worthwhile, but one global flag would be
trivial. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu