Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!howland.reston.ans.net!newsfeed.internetmci.com!in1.uu.net!in-news.erinet.com!bug.rahul.net!a2i!kaiwan.kaiwan.com!pell.pell.chi.il.us!there.is.no.cabal
From: orc@pell.chi.il.us (Orc)
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Followup-To: comp.os.linux.advocacy
Date: 18 Feb 1996 21:10:30 -0800
Organization: Department of Atomic Text Units
Lines: 55
Message-ID: <4g90o6$8n7@pell.pell.chi.il.us>
References: <4er9hp$5ng@orb.direct.ca> <4g0l6o$gcl@park.uvsc.edu> <4g2213$e3f@cebaf4.cebaf.gov> <DMyw8D.Dy@xlan.hil.de>
NNTP-Posting-Host: pell.pell.chi.il.us
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14626 comp.os.linux.development.system:18367
In article <DMyw8D.Dy@xlan.hil.de>, Ingo Paschke <ipaschke@xlan.hil.de> wrote:
>Hi!
>
>doolitt@recycle.cebaf.gov (Larry Doolittle) writes:
>
>>Terry Lambert (terry@lambert.org) wrote:
>
>>: Unordered writes (the result of async writes without delay
>>: ordering) are not only "arguably" unsafe, they are *provably*
>>: unsafe using stochastic methods and/or relatively simple
>>: mathematical models you can find in almost any textbook on
>>: database theory (a file system is a type of database).
>
>>They are only unsafe if the system crashes. My experience
>>with Linux is that it _doesn't_crash_.
>
>"I don't need no stinkin' seat belts or airbags in my car. It simply doesn't
>crash."
Well, actually when it crashes it doesn't seem to make much of a
difference. I have had more than my share of catastrophic crashes on
machines running the ext2fs, and can count the number of scrambled files
on the fingers of a potato. lost+found certainly has gotten its share
of scrambled files when either md has lost it under heavy load or I've
put one too many devices on a power supply and had drives turn off when
driven under heavy load or had systems lock out when I attempt to dma to
or from memory which is too slow, but ext2fs has been really good at not
preserving files that are garbaged (*).
Perhaps it's because the ext2fs was designed with async i/o in mind.
Perhaps it's because I'm the luckiest man on the planet when it comes to
recovering from system crashes. Perhaps it's been the phase of the moon
every time I've had a machine crash or pulled the plug to prevent a rm
from committing (this is one of these things that I was warned against
when being an administrator of a BSD machine, because it would leave
inodes in drifts all over the floor. Good thing I didn't listen to
that bit of advice.)
I just wonder why I've never heard the disaster stories about people
having ext2fs's garbaged when their systems crash, while I've heard
repeated stories about ffs'es putting random debris in files after a
crash. It _could be pure blind luck. It could be design (I'm certainly
enjoying reading the Viva fs article; many thanks to the people who gave
me pointers to its location.) I certainly don't know, but I do think
these dire stories about ext2fs being icky because it's defaulting to
async are equally as convincing as the bogus 'proofs' that ffs is faster
because it's being compared to ext2fs on a different fucking(*)
operating system.
____
david parsons \bi/ Followups directed appropriately
\/
(* community standards require profanity in .advocacy and alt.flame)