Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.hawaii.edu!ames!usenet.kornet.nm.kr!xpat.postech.ac.kr!news.kreonet.re.kr!usenet.seri.re.kr!news.cais.net!news.jsums.edu!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:36:26 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 75
Message-ID: <4gdida$qnc@park.uvsc.edu>
References: <4er9hp$5ng@orb.direct.ca> <311250C2.2781E494@public.uni-hamburg.de> <strenDM7Gr4.Cn2@netcom.com> <DMD8rr.oIB@isil.lloke.dna.fi> <4f9skh$2og@dyson.iquest.net> <DMI5Mt.768@pe1chl.ampr.org> <4fophn$ahl@park.uvsc.edu> <DMrCtI.3KC@pe1chl.ampr.org> <4ftl64$fjs@park.uvsc.edu> <DMv9HD.8Lv@pe1chl.ampr.org> <4g5jsp$28m@park.uvsc.edu> <DMzqyD.Dp0@pe1chl.ampr.org>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14162 comp.os.linux.development.system:17779
rob@pe1chl.ampr.org (Rob Janssen) wrote:
] >Then this is my "or you have outdated tools" case.
]
] Why were the writes done sync back then, when the accompanying tools
] could not fix the system anyway? Just to annoy the users?
Async writes of non-structural data were an optimization that
came later, as part of the Net/2 release.
In the file ufs_dir.c in the SVR4 sources (and in the Net/2 code
that I can't directly reference because of the USL/UCB consent
decree), there was introduced an async write that *should* have
been a sync write.
I corrected this in the UnixWare code and reported it in the
BSD code (where it was corrected by others).
Obvious you are running stale code. Contact your system vendor.
] Why is it always only your own system that does things right,
] and not those systems that others introduce as examples of
] things going wrong *despite* sync writes?
Because I'm a kernel hacker employed full time to work on file
system code and you're not?
The failure of UFS you describe, if it is in fact taking place,
is the result of a bug introduced by an overambitious optimizer,
and not caught by an underambitious commercial integrator.
] >Binary will always yield a number; atoi(ASCII) won't always yield
] >a number.
]
] Precisely. That is a reason to use ASCII. To have redundancy, and
] hence be able to check for errors.
If you will remember correctly (if not, I've saved much of this
thread, or you can use Dejanews), your original failure case
*required* no redundant check as part of the chain of events
leading to the failure.
] >If you want a file system where file data can't be corrupted,
] >contact IBM for JFS, TransArc for AFS, or Veritas for VXFS.
] >The code is commercially available for the right price.
]
] The Veritas filesystem was available for that box, and indeed
] during a test it turned out to be a lot better. Interestingly
] enough it once failed during the "tar xf and pull the plug"
] test, but this was never reproduced.
Yeah. It relies on soft handling of hard errors; a bad driver
(like the original UnixWare 1.x IDE/WD driver) can result in
timeouts marking massive areas of the disk as "bad" using a
soft marking mechanism.
Personally, I think media perfection code belongs in a physical
to logical device translation abstraction layer.
] >If you want to keep the file system structure from being
] >corrupt on a file system other than one of these, mount sync.
]
] To re-iterate: this has not helped in the above case.
] Maybe it works on your system. On that commercial box it did
] not work, and we only had the benefit of the slowness.
To reiterate: contact your system vendor for a fix. It is not
an inhernet bug in design in UFS, it is a bug in implementation
on that particular platform. Make them correct it.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.