Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:3921 comp.os.linux.misc:28614 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!EU.net!Austria.EU.net!newsfeed.ACO.net!news.iif.hu!goliat.eik.bme.hu!usenet From: pink@fsz.bme.hu (Szabolcs Szigeti (PinkPanther)) Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc Subject: Re: Meta-data (Was:LINUX SUCKS!!!!) Date: 2 Nov 1994 09:44:05 GMT Organization: Department of Process Control, Technical University of Budapest, Hungary Lines: 55 Distribution: world Message-ID: <397n15$3fe@goliat.eik.bme.hu> References: <395u3t$ape@epiwrl.entropic.com> Reply-To: pink@fsz.bme.hu NNTP-Posting-Host: bagira.fsz.bme.hu In article ape@epiwrl.entropic.com, kenh@entropic.com (Ken Hornstein) writes: >In article <CHRISB.94Nov1123540@stork.cssc-syd.tansu.com.au>, >Chris Bitmead <chrisb@stork.cssc-syd.tansu.com.au> wrote: >>In article <38up48INN1o5e@rs1.rrz.Uni-Koeln.DE> se@FileServ1.MI.Uni-Koeln.DE (Stefan Esser) writes: >> >>>The filesystem is one of the parts, where >>>BSD is far more advanced than Linux, in >>>both speed and robustness (nobody in their >>>right mind would use the option to switch >>>off synchronous metadata updates under BSD, >>>since this might void your filesystem in >>>case of a crash, as is the default under >>>Linux). >> >>Nobody in their right mind would want it turned on since it could cause >>crap meta-data if the system crashes. Better to do it the other way round. >>Write your data first and then update your meta-data. > >There's one thing about this approach that I don't understand: if you write >your data blocks first and your system dies before the meta-data gets written, >how do you know where the data blocks are? If you write the meta-data first, >your filesystem recovery program can at least figure out if your meta-data >is bogus or not. > >Polite replies welcome. > Right. If you write data first, then metadata, and your system crashes in between, then you might end up in a situation, when the filesystem seems normal, but somewhere there is wrong data written. In other words, that write, when the os crashed, looks to be completed successfully, when in fact it isn't. If you write metadata first, this is much less likely to happen. Since i haven't used linux extesively, i can't comment on it, but i did experiment with NetBSD a lot, including testing fs reliability (for example by pressing reset in middle of heavy disk activity) and never ever lost files. The worst thing that ever happened is that one file ended up in lost+found. By "never losing files" i mean that i never lost any file that was already on the disk, and never got corrupted files. So for example during a compile i either got a good object or no object at all. This means that if the object is there, then it is not corrupted. BTW.: anyone experimented with NetBSD's (4.4BSD's) lfs, concerning reliability? --- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |You are not expected to understand this | Szabolcs Szigeti | | -- Ken Thompson in swtch() -- | Internet: pink@fsz.bme.hu | ----------------------------------------------------------------------------- | Visit our ftp site at: ftp.fsz.bme.hu | | Look at http://www.fsz.bme.hu | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=