*BSD News Article 63087


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.