Re: filesystem reliability

From: Robert Heller (heller_at_deepsoft.com)
Date: 10/23/03


Date: Wed, 22 Oct 2003 23:39:04 +0000


  mike420@ziplip.com,
  In a message on Wed, 22 Oct 2003 04:57:48 -0700 (PDT), wrote :

m> Unix-Haters' book www.simson.net/ref/ugh.pdf
m> appears to suggest that some filesystems
m> on some OSes (LispM?) weren't vulnerable to things like power
m> failures.

Most Lisp Machines were effectively diskless. The disk was used mostly
for the boot image. Note that for the most part Lisp Machines were
single user machines as well and had fairly minimal multi-processing
ability (mostly multi-*threaded*). In many ways the Lisp Machine 'OS'
was more like CP/M (or like early MacOS) than like UNIX.

Oh, there really isn't any such thing as a file system that is
'invulnerable' to power failures and such. Just file systems that are
not very vulnerable to power failures and such. Mostly this is more the
O/S in use. If the O/S *always* flushes every I/O in a more or less
atomic way, the disk is always up to date and the in memory state is
exactly equal to the on disk state. So long as power is not removed
during an actual disk write operation, the file system is effectively
protected from power loss. Since disk write operations are short and
don't come often, the probability is really high that a power failure
will not hurt the file system.

The catch is this: disk writes are (relatively speaking) slow relative
to everything else that is going on (actual computation). The totally
synchronous type of operation is only tolerable for a single user /
single 'tasking' system. Such as is the case for Lisp Machines or
CP/M-80 boxes or even MS-DOS on an old 8088 system.

With a multi-user, multi-tasking O/S, such as UNIX, doing a 'sync' at
*every* disk write operation would just not be tolerable, unless the disk
was really really fast, compared to the processor. Note that even if
you did a sync at every disk write operation and even if the disk was
fast enough, with many users, the disk write frequency would increase,
which increases the probability of a power failure during a disk write.

m>
m> If this is true, why aren't the same filesystems used under
m> modern OSes (*NIX and Windows)? AFAIK all RW filesystems
m> on all of these OSes need to be checked after crashes.

Journaling file systems don't need to be checked. Most UNIX systems now
use journaling file systems. The journal is a low cost way of keeping a
'log' of disk writes. The journal writes have a lower overhead that
continuous syncing would have.

m>
m>

                                     \/
Robert Heller ||InterNet: heller@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || heller@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153

                                                                                                              



Relevant Pages

  • Re: disk check vs scandisk
    ... upon power being restored, no scan disk came on ... > I am not a file system expert, but my guess is that your "xp home ... > Microsoft Product Support Services White Paper ...
    (microsoft.public.windowsxp.basics)
  • Re: Open source storage
    ... you lose power while XFS is building its extant, ... power loss: the defined semantics of any normal Unix-style file system ... flushed to disk may or may not be on the disk, in whole or in part, ...
    (comp.arch.storage)
  • Re: Open source storage
    ... you lose power while XFS is building its extant, ... power loss: the defined semantics of any normal Unix-style file system ... flushed to disk may or may not be on the disk, in whole or in part, ... I see your point, but it strikes me as one of the 'a little bit pregnant' variety: absent explicit write-through or cache-flush control, *any* Unix file system will tend to produce data inconsistencies after interruption, the only question being just how many. ...
    (comp.arch.storage)
  • Re: disk check vs scandisk
    ... upon power being restored, no scan disk came on ... I am not a file system expert, but my guess is that your "xp home ... Microsoft Product Support Services White Paper ...
    (microsoft.public.windowsxp.basics)
  • disktab for VPC Disk
    ... I'm trying to optimize the disk access of NEXTSTEP on Virtual PC 5.0.4. ... Maximum size of NeXT file system is 2GB. ... programs in the initial 8 sectors of the device. ... The number of cylinders per cylinder group in a file system. ...
    (microsoft.public.mac.virtualpc)