Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!news.gmi.edu!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!swrinde!sdd.hp.com!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: async or sync metadata [was: FreeBSD v. Linux]
Date: 17 Feb 1996 00:00:30 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 67
Message-ID: <4g35qu$esr@park.uvsc.edu>
References: <4er9hp$5ng@orb.direct.ca> <4f9skh$2og@dyson.iquest.net> <DMI5Mt.768@pe1chl.ampr.org> <4fi6gq$3tr@dyson.iquest.net> <4fjodc$o8j@venger.snds.com> <4fopq4$ahl@park.uvsc.edu> <4fu1k2$6su@usenet.srv.cis.pitt.edu>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14481 comp.os.linux.development.system:18175
hahn@neurocog.lrdc.pitt.edu (Mark Hahn) wrote:
] safety implies stable storage, when both data and its meta
] are safely on some media. logs are a way to make it much
] less expensive to achieve stability.
I disagree; safety implies the ability to recover to a *known*,
externally concsistent state, not just an internally consistent
state.
I agree that logs are one possible mechanism to implement this.
] > You don't know what you are talking about. I have referenced
] > both papers and mathematical models for file system recovery
] > to refute this specious claim. The only thing I have seen from
] > the opposition is bind assertion. Blind assertion is not proof.
]
] neither is an appeal to authority.
I agree. That's why I referenced the papers themselves rather
than statements by the authors of the papers.
] the question is how much async/async (meta/data) is more
] dangerous or unappealing than async/sync. this is largely
] subjective, hinging upon how you feel about the idea of
] random data winding up in files that fsck clean.
Dangerous/not dangerous is objective, if we can agree on a
definition of "danger". I define danger as the probability
that you will get something other than what you wanted to
get when you engage in an activity. Determinism eliminates
danger entirely.
Unappealing/appealing is, indeed, subjective. All I can say
is that "appeal" is what you use to market when your customer
is technically naieve and either can't understand the technical
argument, or when the technical argument isn't in your favor.
What you call "async/sync", as implemented by UFS, can *not*
result in "random data winding up in files" after an fsck,
short of requiring a hardware failure.
On the other hand, "async/async" in UFS (the non-default
configuration) or Ext2fs (the default configuration) *can*
result in "random data winding up in files" after an fsck.
I haven't seriously examined the Ext2fs "async/sync" case,
since I believe a serious examination would require a full
branch path analysis and subsequent computation of transitive
closure over the resulting state graphs. I don't have time
to do full SQA analysis on any old software. Feel free to
do the work yourself, since you've elected yourself advocate.
] corruption is possible in either case. if you make log entries
] when any async block becomes stable, this can hardly be called
] async.
Arguably true. Async is inherently evil; getting rid of anything
you "can call async" is a unilateral good. Async is *not* the
only way to achieve the desired concurrency wins.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.