*BSD News Article 48314


Return to BSD News archive

Xref: sserve news.software.nntp:14954 comp.unix.bsd.freebsd.misc:4302 comp.os.linux.advocacy:16078
Path: sserve!euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!news.uoregon.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!news.cac.psu.edu!news.math.psu.edu!barr
From: barr@math.psu.edu (Dave Barr)
Newsgroups: news.software.nntp,comp.unix.bsd.freebsd.misc,comp.os.linux.advocacy
Subject: Re: Sun/Solaris or Pentium/Linux for new server ?
Date: 4 Aug 1995 18:51:05 GMT
Organization: Mathematics Department, The Pennsylvania State University
Lines: 26
Distribution: inet
Message-ID: <3vtq6p$18d@dodgson.math.psu.edu>
References: <3vlpgk$rdk@graphite.comco.com> <3vpg3g$q35@shell2.best.com> <3vq3if$jmp@dodgson.math.psu.edu> <3vrt40$74q@gate.sinica.edu.tw>
NNTP-Posting-Host: augusta.math.psu.edu
Cc: 

In article <3vrt40$74q@gate.sinica.edu.tw>,
Brian Tao <taob@gate.sinica.edu.tw> wrote:
>In article <3vq3if$jmp@dodgson.math.psu.edu>, Dave Barr <barr@math.psu.edu> wrote:
>>
>>Linux's ext2 is faster than *BSD FFS, especially in the areas that
>>count with respect to news (directory updates and file creation).
>
>    I thought this is mostly do to the asynchronous updates of
>directory metadata.  That sounds a little too risky to run on a busy
>news server...

Please, don't speculate without investigating.

It has been shown previously that asynchronous updates of metadata
is no more prone to filesystem corruption than synchronous ones.

Unsync'd blocks are unsync'd blocks.  The fact that it is directory
info or block info makes no difference if you sync in the correct order.
Syncing metadata synchronously just improves the possiblity that files will
be corrupted, indetectable to fsck.  I've seen this all the time on
SunOS.  ext2's not perfect, but neither is FFS.

Please see the thread "ANNOUNCE: Linux/PowerPC Kernel" in
comp.os.linux.development.system.  <3vptji$mbm@kruuna.helsinki.fi>

--Dave