Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!seismo!rlgvax!cvl!umcp-cs!tom
From: tom@umcp-cs.UUCP
Newsgroups: net.arch
Subject: Re: Why not virtual files?
Message-ID: <6845@umcp-cs.UUCP>
Date: Tue, 1-May-84 18:29:55 EDT
Article-I.D.: umcp-cs.6845
Posted: Tue May  1 18:29:55 1984
Date-Received: Thu, 3-May-84 19:43:56 EDT
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 31

Traditional, disk based, filesystems have several important
advantages over memory-mapped filesystems in the event
of a crash.

Since traditional filesystems force the process to wait for
the actual disk access, they are kept more up to date (on disk)
than a memory-mapped filesystem would be (unless you force 
a disk write after each file write, in which case you lose
some of the performance of a memory-mapped filesystem).
More importantly, your process must have a way to know
when data it has written is safely non-volitile.

A file that is in memory is an easy victim to the runaway
rabid cpu, and will have to be backed up to its disk
saved previous state if it is to be salvaged reasonably.
A disk controller is far safer from accidental file munging,
and disk files usually weather cpu crashes.

Clearly the memory-mapped filesystem is much faster than
a traditional filesystem, but these issues must be
considered.  The problem of cpu plague will even remain
when we can afford to use non-volatile main memory.

With programmers getting more and more used to large chunks
of (virtual) memory, a hardware breakthrough will be required
to build a real machine with non-volitile memory.

	Tom Melton
	University of Maryland
	tom@maryland
	...decvax!harpo!seismo!umcp-cs!tom