Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.arch
Subject: Re: Fast /tmp
Message-ID: <3734@auspex.auspex.com>
Date: 24 Jul 90 02:13:08 GMT
References: <10776@spool.cs.wisc.edu>
Organization: Auspex Systems, Santa Clara
Lines: 14

>Anyone care to enlighten us about Ohta's scheme (without just
>pointing to a ref)? I've seen it mentioned in this thread a number of 
>times now without any description and I'm curious how it works.

From the paper, it works by having a mount option that undoes the
"ordered write" changes done by, say, Berkeley, to make sure that the
file system's data structures on disk aren't in a seriously inconsistent
state at any time.  Thus, *all* file system writes can be delayed
(write-behind), including writes to directories and inodes.

The idea is that you do this on file systems the survival of whose contents
you don't care all that much about, e.g. "/tmp".  The same rationale is
used for, say, Berkeley's "virtual memory disk" and Sun's "virtual
memory file system" in 4.1.