Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!inferno.mpx.com.au!goliath.apana.org.au!news.syd.connect.com.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!europa.chnt.gtegsc.com!gatech!swrinde!sdd.hp.com!hamblin.math.byu.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: 20 Feb 1996 22:20:17 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 69
Message-ID: <4gdhf1$qnc@park.uvsc.edu>
References: <4er9hp$5ng@orb.direct.ca> <4fg8fe$j9i@pell.pell.chi.il.us> <311C5EB4.2F1CF0FB@freebsd.org> <4fjodg$o8k@venger.snds.com> <4fo1tu$n31@news.jf.intel.com> <DMrCE4.3HF@pe1chl.ampr.org> <4ftjt9$fjs@park.uvsc.edu> <DMv8w7.8H4@pe1chl.ampr.org> <4g5ivp$28m@park.uvsc.edu> <DMzqnM.DnK@pe1chl.ampr.org>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14723 comp.os.linux.development.system:18489
rob@pe1chl.ampr.org (Rob Janssen) wrote:
] >1) Sync enhances the security of your files following a
] > crash and makes sure that part of one of your files
] > does not end up in someone elses hands.
]
] There is no proof that this will happen with ext2fs, and it is
] not likely that it will.
The probability is that it will *not* happen.
The probability, however, is non-zero.
The mathematical *possibility* is just as damning as anecdotal
experience.
Security deals with probability, not anecdotes about "this happened
to me when I did thus and such...".
] >2) Sync increases the probability that things you did
] > right before the machine went down on you aren't going
] > to get lost.
]
] This is just plain wrong, unless both data and metadata are
] written sync.
"Things" does not refer only to data changes; it also refers to
file system structure changes.
As stated before, data integrity is an application problem for
most file systems today (exceptions noted).
] >3) Sync makes your machine go slower on a bogus-as-hell
] > create 1000 files/delete 1000 files benchmark that
] > really doesn't mimic normal system usage at all.
]
] Except when the machine is used as a news server, or when packages
] are being installed on it.
Both of which have been acknowleged as acceptable use of async
mounts, and both of which are special cases where you can recreate
the data from external sources.
I would caution that a news server could lose local user posts;
it is more reasmonable to use the machine as a transfer host
than as a posting host if you mount the drives async.
] >4) Sync makes no difference in user perception of speed
] > unless you're the type of user who lives to run bogus
] > benchmarks, and then claim they represent a single
] > figure-of-merit to use when picking your machine.
]
] I'm very sure that the abysmal performance of news expiry and
] unbatching on the machine I discussed before is due to the sync
] metadata writes. You call that a bogus benchmark.
No. I called the lmbench create/delete "benchmark" bogus.
Use of a system for news services is not "benchmarking". A
"benchmark" needs to be repeatable under laboratory conditions.
A benchmark must produce a "figure of merit" for it to be non-bogus.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.