Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!act.news.telstra.net!psgrain!charnel.ecst.csuchico.edu!csusac!csus.edu!news.ucdavis.edu!agate!ihnp4.ucsd.edu!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!in1.uu.net!EU.net!Austria.EU.net!news.aut.alcatel.at!atusc73!ladavac
From: ladavac@aut.alcatel.at (Marino Ladavac)
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Followup-To: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Date: 27 Feb 1996 13:00:41 GMT
Organization: Alcatel Austria AG
Lines: 59
Message-ID: <4guv9p$nba@atusks02.aut.alcatel.at>
References: <4gejrb$ogj@floyd.sw.oz.au> <4gilab$97u@park.uvsc.edu> <4giqu8$aqk@park.uvsc.edu> <4gira2$a9d@park.uvsc.edu> <hpa.31321eee.I.use.Linux@freya.yggdrasil.com>
NNTP-Posting-Host: atusc73.aut.alcatel.at
X-Newsreader: TIN [version 1.2 PL2]
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14806 comp.os.linux.development.system:18568
H. Peter Anvin (hpa@freya.yggdrasil.com) wrote:
: Followup to: <4gira2$a9d@park.uvsc.edu>
: By author: Terry Lambert <terry@lambert.org>
: In newsgroup: comp.os.linux.development.system
: >
: > mday@park.uvsc.edu (Matt Day) wrote:
: >
: > [ ... ]
: >
: > ] Synchronous metadata updates suck.
: >
: > Absolutely *nothing* sucks worse than losing data.
: >
: > Anything that works is better than anything that doesn't.
: >
: The problem is, sync metadata updates do *not* help you avoid losing
: data. It helps you from losing *files*. The two are not the same,
: since sync metadata doesn't help you make sure there is anything
: reasonable IN those files!
: Hence, given your last criterion, async metadata is better. It does
: what it claims to (work quickly), whereas sync metadata does not (help
: you avoid data loss).
Alas, contrary to your observation:
1) Ordered metadata is a win. Quite simply, it guarantees that the files
*other*than*the*ones*being*written*to*at*the*time*of*the*failure* will
not be damaged. Unordered metadata gives no such guarantees.
If the filesystem does not use ordered metadata writes, the fsck cannot
repair it deterministically--i.e. you *can*lose*the*whole*filesystem*.
This means that the possibility for a much greater data loss exists
(unless you have a trivial filesystem with zero files.)
Please note that it is not possible to *switch* file contents in a
properly implemented Berkeley FFS. Most importantly, the argument
of blocks of a previously deleted file appearing in a newly created
file *after*the*fs*has*been*fsck'd* is bogus.
2) Sync. vs. async. metadata is a bogon. In the Berkeley FFS case, sync
is the implementation of metadata write ordering. It is possible, but
more difficult, to implement delayed ordered metadata updates.
Aside, most of the current confusion about the perceived insecurity of
FFS file contents stems from the (flawed) article:
<idletimeCrGqzv.L9L@netcom.com> by idletime@netcom.com (Totally Lost)
(who, I assume, is John L. Bass) and its predecessors posted to
comp.benchmarks
comp.os.linux.development
comp.sys.sun.admin and
comp.security.unix
on Thu, 16 Jun 1994 00:07:07 GMT
I can re-mail or re-post the article if that should be desired.
/Alby