Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!kettle.magna.com.au!news.magna.com.au!cbitmead From: cbitmead@versant.versant.com.au Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux Date: 26 Feb 1996 06:38:50 GMT Organization: MAGNADATA Internet Services Lines: 91 Message-ID: <CBITMEAD.96Feb26173656@versant.versant.com.au> References: <4er9hp$5ng@orb.direct.ca> <311C5EB4.2F1CF0FB@freebsd.org> <4fjodg$o8k@venger.snds.com> <4fo1tu$n31@news.jf.intel.com> <4frdur$hq@galaxy.ucr.edu> <4g0jll$8l9@park.uvsc.edu> Reply-To: cbitmead@versant.com NNTP-Posting-Host: gw.versant.com.au In-reply-to: Terry Lambert's message of 16 Feb 1996 00:38:13 GMT Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:15102 comp.os.linux.development.system:18907 In article <4g0jll$8l9@park.uvsc.edu> Terry Lambert <terry@lambert.org> writes: >grif@corsa.ucr.edu (Michael Griffith) wrote: >] In article <4fo1tu$n31@news.jf.intel.com>, >] Mike Haertel <haertel@ichips.intel.com> wrote: >] |Then they claim that async metadata update is superior, >] |because it doesn't have this problem. >] | >] |FALSE! >] >] You are quite correct. If I was misleading in this regard, I >] apologize. The real intent of the discussion was to show that >] async was no worse than sync metadata. However, if you add >] ordered writes, you eliminate the problem. > >Sync metadata is an implementation of ordered writes. It's >about as trivial an implementation as you can possibly devise, >but it *is* one. Except that it is the wrong order. The correct way is to write the data first and then the meta-data. This ensures consistent data. > >If you keep confusing the issues of container object content >integrity and general referential integrity, I will have to >keep correcting you. > > >] The performance implications are quite substantial AND sync >] metadata doesn't really gain you anything in terms of reliability >] (it may actually hurt a bit, because you are more likely to have >] unordered writes.) Given this, why bother with sync metadata? > >Wrong again. Ugh. Please read: > >http://www.pdos.lcs.mit.edu/~ganger/papers/osdi94.ps.Z > > Metadata Update Performance in File Systems , > by Gregory R. Ganger and Yale N. Patt. > Appears in the Proceedings of the USENIX Symposium on > Operating Systems Design and Implementation (OSDI) , > Nov. 1994, pp. 49-60. > >Also read: > >http://www.pdos.lcs.mit.edu/~ganger/papers/CSE-TR-254-95/CSE_TR_254_95.ps.Z > > Soft Updates: A Solution to the Metadata Update Problem > in File Systems , > by Gregory R. Ganger and Yale N. Patt. > Published as report number CSE-TR-254-95 by the University > of Michigan, Ann Arbor, in August 1995. > > > >] Having inconsistent filesystem structures really isn't the issue. A >] hard failure where you know you have to restore from backups because >] fsck can't figure things out is a lot better than silently corrupting >] data. > >Any time you boot a system and the clean bit wasn't set during >the shutdown process, you may have "silently correpted data". > >Write your applications so that they recover from container >object failures and get over it already. > >] The study may be worthwhile, but I am holding out for ordered >] writes. > >Ordered writes don't do anything in terms of file system consistency >that synchronous writes already do. Ordered writes just have a >higher concurrency than synchronous writes. There is no other >effective difference. > >] A comparison between properly ordered writes and the current >] situation would me much more interesting. Anybody have good >] ideas for the setup of the experiments? > >You can only prove failure experimentally; you can not prove >success. > >Just because it didn't fail on you when you were using it doesn't >mean that it will never fail. > > > Terry Lambert > terry@cs.weber.edu >--- >Any opinions in this posting are my own and not those of my present >or previous employers.