Unix-Haters' book www.simson.net/ref/ugh.pdf
appears to suggest that some filesystems
on some OSes (LispM?) weren't vulnerable to things like power
failures.
If this is true, why aren't the same filesystems used under
modern OSes (*NIX and Windows)? AFAIK all RW filesystems
on all of these OSes need to be checked after crashes.
·······@ziplip.com wrote:
> Unix-Haters' book www.simson.net/ref/ugh.pdf
> appears to suggest that some filesystems
> on some OSes (LispM?) weren't vulnerable to things like power
> failures.
>
> If this is true, why aren't the same filesystems used under
> modern OSes (*NIX and Windows)? AFAIK all RW filesystems
> on all of these OSes need to be checked after crashes
... as long as the filesystem is flushed and nothing is
going on, at the moment of a crash, the filesystem should
be intact.
of course, you havent mentioned how these filesystems
implement "not vulnerable to power failures" functionality.
there ARE ways to protect your filesystems from stuff like
this. and with modern, journaled filesystems, recovery is
quick and painless
.
--
/// Michael J. Tobler: motorcyclist, surfer, skydiver, \\\
\\\ and author: "Inside Linux", "C++ HowTo", "C++ Unleashed" ///
Did you know that clones never use mirrors? "The Devil's Dictionary"
> Unix-Haters' book www.simson.net/ref/ugh.pdf
> appears to suggest that some filesystems
> on some OSes (LispM?) weren't vulnerable to things like power
> failures.
There are a wide range of potential protections. The simplest is
guaranteeing structural integrity in the face of power failure. This form
of protection has been available via Veritas VxFS since at least 1992,
with the release of SVR4.2. Interestingly, that is two years *before* the
UHH was published. A more complex one is atomic transactions. This means
that a given write() (or other operation) either succeeds completely or
fails completely. I don't know what UNIX filesystems implement this, but
ext3 (in data journaling mode) and ReiserFS 4 implement this on Linux.
Rayiner Hashem <·······@mail.gatech.edu> writes:
>> Unix-Haters' book www.simson.net/ref/ugh.pdf
>> appears to suggest that some filesystems
>> on some OSes (LispM?) weren't vulnerable to things like power
>> failures.
>
> There are a wide range of potential protections. The simplest is
> guaranteeing structural integrity in the face of power failure. This form
> of protection has been available via Veritas VxFS since at least 1992,
> with the release of SVR4.2. Interestingly, that is two years *before* the
> UHH was published.
This sort of protection was available on Multics in 1977.
UHH drew most of its material from the Unix Haters mailing list, which
was started in 1987.
> This sort of protection was available on Multics in 1977.
Multics was also intended for a very different class of hardware than
UNIX. IIRC, it wasn't until relatively recently (mid-1990's) that clever
journaling algorithms managed to mitigate most of the performance hit
associated with ensuring metadata integrity.
> UHH drew most of its material from the Unix Haters mailing list, which
> was started in 1987.
They had two years to check their facts...
Rayiner Hashem <·······@mail.gatech.edu> writes:
>> This sort of protection was available on Multics in 1977.
> Multics was also intended for a very different class of hardware than
> UNIX. IIRC, it wasn't until relatively recently (mid-1990's) that clever
> journaling algorithms managed to mitigate most of the performance hit
> associated with ensuring metadata integrity.
Mid '80s. Check out the Cedar file system.
>> UHH drew most of its material from the Unix Haters mailing list, which
>> was started in 1987.
> They had two years to check their facts...
I forgot how widespread Veritas was in 1990.
From: Christopher C. Stacy
Subject: Re: filesystem reliability
Date:
Message-ID: <uekx4h4cu.fsf@dtpq.com>
>>>>> On Thu, 23 Oct 2003 01:00:37 GMT, prunesquallor ("prunesquallor") writes:
prunesquallor> This sort of protection was available on Multics in 1977.
The Symbolics LMFS was written by Bernie Greenberg (a Multics hacker).
LMFS shared many features in common with Multics (although not the
segment model), including pathname syntax and access control lists.
It was designed to be super-reliable even in the face of flaky disk
drives and various kinds of disasters.
·······@ziplip.com wrote:
> Unix-Haters' book www.simson.net/ref/ugh.pdf
> appears to suggest that some filesystems
> on some OSes (LispM?) weren't vulnerable to things like power
> failures.
>
> If this is true, why aren't the same filesystems used under
> modern OSes (*NIX and Windows)? AFAIK all RW filesystems
> on all of these OSes need to be checked after crashes.
"Bad old Unix UFS" used to be pretty bad, vis-a-vis crash handling.
Between Veritas (common on commercial Unixes), Berkeley FFS with soft
updates, and the manifold journalling filesystems on Linux, the degree
of vulnerability has diminished substantially, and the cost of
unexpected power failure has also gone down.
So while the claims about filesystems were true for a long time, they
aren't anymore.
And I'm not sure that much if any of the things pointed at in the UHH
necessarily are improved on in any other system that has proven
common/popular. If Unix is worthy of criticism, Windows is much
moreso...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/languages.html
As of next Monday, MACLISP will no longer support list structure.
Please downgrade your programs.
In article <··············@ID-125932.news.uni-berlin.de>,
Christopher Browne <········@acm.org> wrote:
>And I'm not sure that much if any of the things pointed at in the UHH
>necessarily are improved on in any other system that has proven
>common/popular. If Unix is worthy of criticism, Windows is much
>moreso...
True. But when UHH was written, Windows wasn't even a full-fledged OS, I
think it was still just a facade grafted on top of DOS. The authors were
mainly comparing Unix to the systems that it seemed to be supplanting, not
other up-and-coming systems, since it seemed like a crappy system was
replacing the elegant ones that they'd come to love. If they'd written the
book in the late 90's or now, I'm sure it would have been the Windows
Hater's Handbook instead. Unix has definitely gotten better since they
wrote the book (although many of the criticisms are still valid), while
Windows has encroached on many of the uses that Unix and other operating
systems traditionally owned, and has shown itself to be vastly inferior to
even Unix.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> In article <··············@ID-125932.news.uni-berlin.de>,
> Christopher Browne <········@acm.org> wrote:
>>And I'm not sure that much if any of the things pointed at in the UHH
>>necessarily are improved on in any other system that has proven
>>common/popular. If Unix is worthy of criticism, Windows is much
>>moreso...
>
> True. But when UHH was written, Windows wasn't even a full-fledged OS, I
> think it was still just a facade grafted on top of DOS. The authors were
> mainly comparing Unix to the systems that it seemed to be supplanting, not
> other up-and-coming systems, since it seemed like a crappy system was
> replacing the elegant ones that they'd come to love. If they'd written the
> book in the late 90's or now, I'm sure it would have been the Windows
> Hater's Handbook instead.
Except, of course, that at least one of the authors of UHH
works for Microsoft :-)
> Unix has definitely gotten better since they
> wrote the book (although many of the criticisms are still valid), while
> Windows has encroached on many of the uses that Unix and other operating
> systems traditionally owned, and has shown itself to be vastly inferior to
> even Unix.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
From: Christopher C. Stacy
Subject: Re: filesystem reliability
Date:
Message-ID: <uy8vd2gcw.fsf@dtpq.com>
Checksums on every block, is another feature that LMFS had.
On Wed, 22 Oct 2003 04:57:48 -0700, mike420 wrote:
> If this is true, why aren't the same filesystems used under modern OSes
> (*NIX and Windows)? AFAIK all RW filesystems on all of these OSes need to
> be checked after crashes.
No, filesystems with journaling don't have to be checked
(e.g. ext3, xfs, reiserfs).
Followup-To: comp.os.linux.misc, which I don't read.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
+---------------
| mike420 wrote:
| > If this is true, why aren't the same filesystems used under modern OSes
| > (*NIX and Windows)? AFAIK all RW filesystems on all of these OSes need to
| > be checked after crashes.
|
| No, filesystems with journaling don't have to be checked
| (e.g. ext3, xfs, reiserfs).
+---------------
This is not quite true: journaling filesystems *DO* have to be
processed after a crash -- to finish writes which were journaled
but not yet committed to file space. E.g., XFS filesystems need
to run "xfs_recover" when the system reboots.
What *is* true is that this process is typically several orders of
magnitude faster than "fsck" on old-style filesystems, since only
the portion of the log written since the last full sync needs to be
processed, and the size of that is dependent only on the write rate
at the time of the crash and (unlike old-style filesystems) *not* upon
the total size of the filesystem or its occupancy.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In comp.os.linux.misc Rob Warnock <····@rpw3.org> wrote:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> | No, filesystems with journaling don't have to be checked
> | (e.g. ext3, xfs, reiserfs).
> This is not quite true: journaling filesystems *DO* have to be
> processed after a crash -- to finish writes which were journaled
> but not yet committed to file space. E.g., XFS filesystems need
They also have to be checked in order to be checked. Journals do not
make them immune to corruption, neither software induced nor hardware
induced.
> to run "xfs_recover" when the system reboots.
Peter
In article <······················@speakeasy.net>, Rob Warnock wrote:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> +---------------
>| mike420 wrote:
>| > If this is true, why aren't the same filesystems used under modern OSes
>| > (*NIX and Windows)? AFAIK all RW filesystems on all of these OSes need to
>| > be checked after crashes.
>|
>| No, filesystems with journaling don't have to be checked
>| (e.g. ext3, xfs, reiserfs).
> +---------------
>
> This is not quite true: journaling filesystems *DO* have to be
> processed after a crash -- to finish writes which were journaled
> but not yet committed to file space. E.g., XFS filesystems need
> to run "xfs_recover" when the system reboots.
The phrase "to finish writes" is a little misleading. I suspect in most
cases, more "undoing" takes place that "doing". Eg., freeing an inode that
was allocated, but never written to; or data block that was allocated but not
used. The data that was in cache and not yet sync'd to the disk is gone.
Journaling insures a "consistent" filesystem, not a "complete" filesystem.
--
Dave Brown Austin, TX
> E.g., XFS filesystems need
> to run "xfs_recover" when the system reboots.
That's not true. xfs_recover is for salvaging a damaged filesystem. The
journal replay process (which usually takes only a few seconds per volume)
happens automatically when the filesystem is mounted.