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