Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:1249 comp.os.linux:56351
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!headwall.Stanford.EDU!microunity!iimura
From: iimura@microunity.com (Wally Iimura)
Subject: Re: FYI.. benchmarks on linux and 386bsd
Distribution: inet
Message-ID: <1993Oct15.192920.1628@microunity.com>
Sender: usenet@microunity.com (news id)
Nntp-Posting-Host: moloch.microunity.com
Organization: MicroUnity Systems Engineering Inc.
References: <2CB12A8D.17397@news.service.uci.edu> <MYCROFT.93Oct6054959@duality.gnu.ai.mit.edu> <29klpf$8ae@kralizec.zeta.org.au> <HSU.93Oct15200852@laphroaig.cs.hut.fi>
Date: Fri, 15 Oct 1993 19:29:20 GMT
Lines: 35
hsu@cs.hut.fi (Heikki Suonsivu) writes:
>In article <29klpf$8ae@kralizec.zeta.org.au> bde@kralizec.zeta.org.au (Bruce Evans) writes:
> >for this and therefore risks serious file system corruption should the
>...
> A measly 10 to 20 times faster. This is one thing makes Linux "feel"
>Personally, I would prefer that there would be per-filesystem option to set
>whether you wish file system structure updates done synchronously.
>Normally one wants the system be reasonably stable, but when doing large
>copies of directory trees (like moving contents of one filesystem to
>another) it would be nice to avoid extra cost of doing synchronous IO.
>What would be even better would be a shadow paging filesystem. This would
>avoid need for fsck, avoid synchronous writes (unless explicitly
>requested), you could add filesystem transactions and live backups are
>safer (you can take a snapshot with little cost). Properly designed this
>would probably allow some performance gain, as allocation can be done
>freely, write to the track the head happens to be on, if suitable space is
>available.
>Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
>hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN
>/G=Heikki/S=Suonsivu/O=hut/OU=cs/PRMD=Inet/ADMD=Fumail/C=FI
The LOCUS filesystem that IBM used in its AIX-PS/2 product provided shadow
pages and did atomic commits. This made the filesystem very robust WRT file
corruption as either the old file or the complete new version would be recovered
by fsck. Files that were partially updated when the system crashed would be
flushed by fsck. Since updates are not done "in place", more work needs to be
done and more free space is required by this type of filesystem. Email me
if you would like more information about how this filesystem works.
Wally Iimura
iimura@MicroUnity.com