*BSD News Article 62170


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!news.ecn.uoknor.edu!paladin.american.edu!gatech!newsfeed.internetmci.com!inet-nntp-gw-1.us.oracle.com!news.caldera.com!news.cc.utah.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Date: 16 Feb 1996 01:04:24 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 47
Message-ID: <4g0l6o$gcl@park.uvsc.edu>
References: <4er9hp$5ng@orb.direct.ca> <4fo1tu$n31@news.jf.intel.com> <DMrCE4.3HF@pe1chl.ampr.org> <4ftjt9$fjs@park.uvsc.edu> <jlemonDMtpAz.3rJ@netcom.com>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14371 comp.os.linux.development.system:18038

jlemon@netcom.com (Jonathan Lemon) wrote:
] In this sense, "sync vs async" is a the wrong argument; it should really be
] "ordered vs unordered" instead.
] 
] My question is, does ext2fs preserve ordering, even though it writes metadata
] async?  If not, then it is arguably more unsafe, even from the user's point 
] of view.  (eg: if you have to re-run 'mkfs' on a disk to fix consistency
] problems, then you lose more data than just truncating a couple of files, no?)

By default, it does not.  Its async writes are async, not
delayed ordered.

The former USL, former Novell/USG has a patent pending on delayed
ordered writes, so one should be careful if considering their
implementation.  USL is known to take IP issues seriously, even
when they are wrong (since when has prior art stopped a software
patent -- look at compression and encryption patents).


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).

This is why I argue *against* making async writes the default
in FreeBSD every time someone brings up that unutterbly bogus
create/delete "benchmark" from lmbench and suggests it be
"fixed" by going to async mounting "because it doesn't hurt
anything".  Retch.


Mounting async is thin-edge stuff.  You should only do it if
you are prepared to rebuild the file system if you have an
event after a lot of disk activity but before the sync fires.
A UPS is insufficient, unless you are willing to certify your
OS a "bug free" and "graceful in the face of resource starvation".

Yeah.  I didn't think so.



                                        Terry Lambert
                                        terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.