Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:4034 comp.os.linux.misc:29303 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.uwa.edu.au!nodecg.ncc.telecomwa.oz.au!netbsd08.dn.itg.telecom.com.au!orca1.vic.design.telecom.com.au!picasso.cssc-syd.tansu.com.au!newshost!chrisb From: chrisb@stork.cssc-syd.tansu.com.au (Chris Bitmead) Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc Subject: Re: Meta-data (Was:LINUX SUCKS!!!!) Date: 10 Nov 94 12:34:14 Organization: Telecom Australia - CSSC Lines: 35 Distribution: world Message-ID: <CHRISB.94Nov10123414@stork.cssc-syd.tansu.com.au> References: <395u3t$ape@epiwrl.entropic.com> <397n15$3fe@goliat.eik.bme.hu> <CHRISB.94Nov3150435@stork.cssc-syd.tansu.com.au> <39mkejINN1uab@rs1.rrz.Uni-Koeln.DE> NNTP-Posting-Host: stork.cssc-syd.tansu.com.au In-reply-to: se@fileserv1.MI.Uni-Koeln.DE's message of 8 Nov 1994 01:32:03 GMT In article <39mkejINN1uab@rs1.rrz.Uni-Koeln.DE> se@fileserv1.MI.Uni-Koeln.DE (Stefan Esser) writes: >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 ... My point was that since Linux doesn't do meta-data writes synchronusly, there is a smaller window of time between meta and non-meta updates when if the system goes down, meta-data could point to the wrong thing. Obviously this doesn't mean that Linux has solved the problem. But it does mean that Linux's algorithm, while providing much better performance, actually reduces (slightly) the possibility of corruption.