Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!newsroom.utas.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!usenet.ins.cwru.edu!agate!howland.reston.ans.net!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: 17 Feb 1996 22:12:41 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 68
Message-ID: <4g5jsp$28m@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>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14514 comp.os.linux.development.system:18228
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.
[ ... 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.
It's "modern" because old UUCP used to use ASCII and HDB UUCP
(which is a more recent implementation) doesn't.
[ ... more implementation dependent cruft ... ]
] But, this is all irrelevant to the discussion. The lockfile
] should have been nonexistent, empty, or correct. Then the
] kill would have detected the staleness and there would have
] been no problem.
You forgot "detectably corrupt".
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.
If you want to keep the file system structure from being
corrupt on a file system other than one of these, mount sync.
If you want to keep your apps from being bitten by corrupt
data, then use algorithmic protections, like multistage commits.
In any event, you *will* be screwed by a hardware failure;
even a RAID array is subject to the whims of the controller
it is plugged into.
] I was disappointed that this system, while being so slow at
] mass file creation, still allowed this error.
I'm sure it has an async mount option, so use it (at your own risk).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.