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!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!spool.mu.edu!pravda.aa.msen.com!nntp.coast.net!chi-news.cic.net!newsfeed.internetmci.com!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: <DMrCtI.3KC@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> Date: Wed, 14 Feb 1996 08:56:06 GMT Lines: 46 Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14316 comp.os.linux.development.system:17953 In <4fophn$ahl@park.uvsc.edu> Terry Lambert <terry@lambert.org> writes: >rob@pe1chl.ampr.org (Rob Janssen) wrote: >] In <4f9skh$2og@dyson.iquest.net> root@dyson.iquest.net (John S. Dyson) writes: >] >] >Linux is more vulnerable to filesystem problems due to the delayed writes >] >of metadata (and is the reason that FreeBSD is slower on file >] >create/delete benchmarks.) >] >] It seems to be very hard to get this misconception out of the BSD people's >] heads... >] Sync metadata writes may seem to improve things, but actually it just >] causes your fsck's to return no errors while the files are still >] corrupted. Not necessarily better. >You are confusing file system structure errors with file system >content errors. >File system content errors are the responsibility of an application, >unless you go to a log structured file system with user accessable >transaction tracking interfaces into the log to ensure implied >state across multi-file applications is also consistent. No, I am referring to the situation where an application has written data to a file, the system crashes, and then the file contains other (garbage) data after restart. While fsck reports no errors. I once spent quite some time tracking down why UUCP was hanging. The system had crashed at the moment uux had created a lockfile. A file with 10 bytes of binary garbage existed on the disk after the restart. This is clearly an indication of this problem. The file would not be 10 bytes if the application hadn't done the correct write (and probably even the close), yet the data was not the expected ASCII PID. What made this one nasty, is that the UUCP programs read the file, do an atoi() on it, and then use kill() to check if this PID is existing to know if the lockfile is valid or stale. This failed to work because the atoi returned zero, UUCP (Taylor) did a kill(-1,0) which of course succeeded and thus the lockfile was assumed to be valid and never removed. 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 | +------------------------------------+--------------------------------------+