Great Circle Associates Firewalls
(April 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Intel firewalls: more than just performance
From: kris @ schulung . netuse . de (Kristian Köhntopp)
Organization: entfällt
Date: Tue, 30 Apr 1996 06:25:36 GMT
To: firewalls @ greatcircle . com
References: <199604292231 . PAA19336 @ miles . greatcircle . com>

Firewalls @
 GreatCircle .
 COM writes:
>Dream on. FAT is way flakier than UFS. The difference is that DOS isn't
>kept up 24 hours 365 days, and UNIX generally is.

All this comes down to the issue of metadata update. Metadata is
the strucural information in a file system (i.e. inodes and
indirect blocks as well as directory information in a UNIX fs).
If you want your fs to be stable, you want it's metadata written
out in a specific order (for example, inode data blocks should
always be written out before their corresponding indirect block
and an inode should only be written after all direct data blocks
and indirect data blocks are save on disk).

Synchronous writes is what you have on a DOS system without
SMARTDRV or at least without SMARTDRV write caching. This is
pretty save, because no information is ever lost in the cache.
Synchronous write are also slow, which is why you don't want to
run Windows without such a cache. With SMARTDRV doing write
caching, the DOS filesystem is no longer crash resistant.

BSD systems have (normally) a write cache, but do metadata
update synchronusly. In newer versions of FreeBSD you have the
option to write out metadata asynchronously, if you are willing
to take the additional risk of loosing data due to a power
outage during heavy disk update activity. These synchronous
writes are what you hear (and wait for) when you rm -rf your
/usr/spool/news, for example. Linux does disk updates
asynchronously, unless you mount the disk with the "sync" option
(which causes ALL writes to be syncronous - that's slow!).


There are several options to beat the metadata update
bottleneck. One is used by AIX's JFS. The JFS is a journalled
file system. All write operations are logged to a journal
partition synchrously. Since this journal is written to a linear
buffer without repositioning, it can at least take advantage of
full disk speed. Later these updates are written to the live
partition and deleted from the log, but this is no longer time
critical (if the log is large enough!).

Another option is to do away with the normal FS completely and
use only the log for data storage. Osterhout has done this in
Sprite, an experimental distributed microkernel operating
system, with his LFS (log-structured file system). His
implementation has been substantially improved and generally be
brought to a useable state by Seltzer, Bostic, McKusick and
Staelin ("An Implementation of a Log-Structured File System for
UNIX", USENIX Winter '93, San Diego, CA) in BSD. LFS should be
part of current BSD (at least it seems to be on my Infomagic
BSDisc November '94 - I never installed it). It is blindingly
fast for writes and metadata intensive operations such as file
creation or deletion, but it requires a cleaner process in the
background to reorder the data on disk and to clean out all that
blocks that are no longer being referenced by any inode. LFS
performs badly for transactional update patterns, but quite well
in an development environment.



File systems with synchronous metadata update can recover from
power outages fairly well. No vital data is lost and the fsck is
guranteed to restore the system to a consistent state within
finite time. Unfortunately this time is proportional to the file
system size and can become a unbearable for large file systems.
For example I remember the complaint of one admin using UFS on a
400 Gig RAID on the alpha-osf-managers mailing list who
estimated a fsck recovery time of several days should his
machine come down ungraceful.

File systems that are log-based or log-structured can safely
recover from outages as well, but their recovery time is bound
by the amount of disk activity at the time of the crash, not the
size of the fs. In the case of the above mentioned OSF/1 manager
it would be several minutes, if his machine crashed during heavy
update operations.


If you want to know more about this, you might as well post this
thread to comp.os.linux.development.system and hope that Terry
Lambert reads it. It is guaranteed to push his button. :-)

Kristian
-- 
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897
Fachbegriffe der Informatik einfach erklaert, Teil 27:
"Durch das Volk uebertragene gesellschaftliche Verantwortung in Bezug
 auf die zukuenftige Gestaltung der Informationsgeselltschaft wahrnehmen ..." 
 	== "Das Internet zensieren ..."

Indexed By Date Previous: RE: Intell firewalls: more than just performance
From: Matthew Thompson <mthomps1 @ kiwitech . co . nz>
Next: Re: Intell firewalls: more than just performance
From: Remy NONNENMACHER <remy @ synx . com>
Indexed By Thread Previous: RE: Intel firewalls: more than just performance
From: Matthew Thompson <mthomps1 @ kiwitech . co . nz>
Next: Re: Intel firewalls: more than just performance
From: "<root>" <root @ wolf . microserve . com>

Google
 
Search Internet Search www.greatcircle.com