Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!metro!metro!inferno.mpx.com.au!news.mel.aone.net.au!imci4!newsfeed.internetmci.com!usenet.eel.ufl.edu!news.uoregon.edu!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
Date: 19 Feb 1996 17:50:31 -0800
Organization: I *plonk* LA
Lines: 76
Message-ID: <4gb9d7$6g8@pell.pell.chi.il.us>
References: <4er9hp$5ng@orb.direct.ca> <311C5EB4.2F1CF0FB@FreeBSD.org> <4for2b$art@park.uvsc.edu> <jlemonDMttxH.JyJ@netcom.com>
NNTP-Posting-Host: pell.pell.chi.il.us
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14031 comp.os.linux.development.system:17638
In article <jlemonDMttxH.JyJ@netcom.com>,
Jonathan Lemon <jlemon@netcom.com> wrote:
>In article <4for2b$art@park.uvsc.edu>,
>Terry Lambert <terry@lambert.org> wrote:
>>"Jordan K. Hubbard" <jkh@FreeBSD.org> wrote:
>>] I don't think that the async-vs-sync metadata write issues are worth
>>] debating since the whole topic is truly too subjective for meaningful
>>] discussion.
>>
>>Bah Humbug. See other posts in this thread.
>>
>>When anyone claims some operating system component is not subject
>>to objective, mathematical analysis, they are mistaken.
>>
>>Objective, not subjective.
>>
>>] I would suggest instead simply trying sync vs async on your
>>] own system, being as (in)cautious as you care to be in the
>>] transition, and then post your experiences. People need
>>] concrete evidence here, not abstract debate.
>>
>>Anecdotal evidence is not evidence:
>>
>> "XXX OS has not crashed while I was using it, therefore
>> XXX OS never crashes"
>>
>
>Bah Humbug indeed. Since this was crossposted to c.o.l.d.s, I went over there
>to take a peek. Guess what I found? Not one, not two, but at least _three_
>users who have had problems with ext2fs. Now, I'm _NOT_ claiming that this is
>an inherent problem with ext2fs, and it may not even have anything to do with
>the async/sync issue. But it is "concrete evidence" (Jordan's term) to refute
>the "anecdotal evidence" (Terry's term).
>--
>Jonathan
There's a bit of confusion here, I suspect, about the sort of damage
people are talking about. Stefan Esser pointed out to me (indirectly)
that I, for one, was being fairly loose in what I was talking about, and
that may be the case for everyone in this particular religious war.
There are two sorts of damage that can happen. One is to have an
entire filesystem reduce itself to diced cabbage, leaving (almost, if
you're lucky) nothing accessable, and the other is to have a filesystem
crash, appear to recover, but have the _contents_ of files converted
into diced cabbage. There's no question that the first thing can
happen to the ext2fs -- if the system or driver loses it while writing
bitmaps, a large part of your filesystem will mysteriously cease to
exists; but the second one -- that files will appear to be okay,
only to end up with random garbage in them -- does not appear to
happen very often, if at all (I have had it happen to me, but these
files appear to be best guess recoveries by fsck -- they end up in
lost+found, and don't pretend to be okay.)
Ext2fs is still a bit of a work in progress, so it's possible that
things will mysteriously go wrong with it. But those things are _not_
because it writes things asynchronously, and, similarly, FFSes stability
does not come from it doing synchronous metadata writes (I remember the
early releases of BSD, where FFS would, synchronous metadata or not,
leave inodes all over the floor if the machine ever went down while it
was in full cry.)
____
david parsons \bi/ For this discussion, I'll use 'trashed' to refer to
\/ dead filesystems and 'garbaged' to refer to dead
file contents. Unless it's Wednesday, when 'toasted'
will refer to dead filesystems and 'mangled' refers
to dead file contents. On the third wednesday of
each month, except July, August, and December, 'dead'
will refer to dead filesystems and 'corrupted' to
refer to dead file contents. On the second wednesday
of January, March, and April, however, the meanings
of dead and corrupted will be reversed.
Pay attention now; there will be a short quiz at the
end of the week.