*BSD News Article 62480


Return to BSD News archive

Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!torn!howland.reston.ans.net!EU.net!sun4nl!rnzll3!sys3.pe1chl!rob
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Reply-To: pe1chl@wab-tis.rabobank.nl
Organization: PE1CHL
Message-ID: <DMzqyD.Dp0@pe1chl.ampr.org>
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>
Date: Sun, 18 Feb 1996 21:42:13 GMT
Lines: 62
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14613 comp.os.linux.development.system:18342

In <4g5jsp$28m@park.uvsc.edu> Terry Lambert <terry@lambert.org> writes:

>rob@pe1chl.ampr.org (Rob Janssen) wrote:

>[ ... rob says got crap in his files after a fsck on a commercial
>      UFS implemenation a while ago ... ]

>] The fsck was running in "automatically repair minor defects" mode
>] on rebooting the system.

>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?

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?

>[ ... on crap in a lockfile ... ]

>] >Bogus lockfile data is the reason modern implementations use a
>] >4 byte binary integer instead of an ASCII representation of the
>] >number.  At the very least, a well-written program would check
>] >for the special cases and ensured the PID was > 1 to avoid kill()
>] >side-effects.  At worst, it would have done an isdigit() on the
>] >least significant digit in the lockfile read buffer.
>] 
>] Huh?  Binary is better than ASCII?  And why is it "modern"?
>] I think an ASCII representation with proper checks is much more
>] resistant to errors than a binary representation (which can only be
>] checked on range).
>] My suggestion is to check all digits to be space, digit or \n.

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

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

Rob
-- 
+------------------------------------+--------------------------------------+
| Rob Janssen         rob@knoware.nl | BBS: +31-302870036 (2300-0730 local) |
| AMPRnet:       rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+------------------------------------+--------------------------------------+