*BSD News Article 37640


Return to BSD News archive

Xref: sserve comp.os.386bsd.misc:4017 comp.os.linux.misc:29156
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!dog.ee.lbl.gov!overload.lbl.gov!lll-winken.llnl.gov!sol.ctr.columbia.edu!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!scsing.switch.ch!news.dfn.de!rrz.uni-koeln.de!RRZ.Uni-Koeln.DE!RRZ.Uni-Koeln.DE!news
From: se@fileserv1.MI.Uni-Koeln.DE (Stefan Esser)
Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc
Subject: Re: Meta-data (Was:LINUX SUCKS!!!!)
Date: 8 Nov 1994 01:32:03 GMT
Organization: Institute of Nuclear Physics, University of Cologne, Germany
Lines: 32
Distribution: world
Message-ID: <39mkejINN1uab@rs1.rrz.Uni-Koeln.DE>
References: <395u3t$ape@epiwrl.entropic.com> <397n15$3fe@goliat.eik.bme.hu> <CHRISB.94Nov3150435@stork.cssc-syd.tansu.com.au>
NNTP-Posting-Host: fileserv1.mi.uni-koeln.de

In article <CHRISB.94Nov3150435@stork.cssc-syd.tansu.com.au>, chrisb@stork.cssc-syd.tansu.com.au (Chris Bitmead) writes:
|> No it can't. Think about it. If you always wrote data, then double indirect
|> blocks, then indirect blocks then inodes then nothing can *ever* point to
|> the wrong thing. The worst that can happen is that if you wrote something
|> to the filesystem, and the system crashes you could lose it if it hadn't
|> been flushed to disk.
|> 
|> If the system has written some data blocks to disk which havn't got any
|> inodes or indirect blocks pointing to them yet, well fsck will just tag
|> them as free blocks. At least you don't get crap in files that you can get
|> with synchronus meta-data writes.

Quite right.

|> Linux does not implement the above scheme of writing data before
|> meta-data, but since it does everything asyncronusly both meta and
|> non-meta are more likely to get to disk at the same time, thus lessening
|> the chances of corruption.

No, there is no "same time" when doing disk updates. The best you 
can get is metadata after data half the time on average, but if the
number of data blocks (or indirect blocks) is larger than the number
of blocks of i-node information, then the chance that the metadata
gets written after anythings else is approaching zero ...

STefan
-- 
 Stefan Esser				Internet:	<se@ZPR.Uni-Koeln.DE>
 Zentrum fuer Paralleles Rechnen	Tel:		+49 221 4706010
 Universitaet zu Koeln			FAX:		+49 221 4705160
 Weyertal 80
 50931 Koeln