Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!news.dacom.co.kr!news.uoregon.edu!kaiwan.kaiwan.com!pell.pell.chi.il.us!there.is.no.cabal
From: orc@pell.chi.il.us (Orc)
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Date: 21 Feb 1996 19:41:20 -0800
Organization: Department of Atomic Text Units
Lines: 42
Message-ID: <4ggol0$38h@pell.pell.chi.il.us>
References: <4er9hp$5ng@orb.direct.ca> <4g33tp$esr@park.uvsc.edu> <4g57cj$gc3@pell.pell.chi.il.us> <4g5k95$28m@park.uvsc.edu>
NNTP-Posting-Host: pell.pell.chi.il.us
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14320 comp.os.linux.development.system:17958
In article <4g5k95$28m@park.uvsc.edu>,
Terry Lambert <terry@lambert.org> wrote:
>orc@pell.chi.il.us (Orc) wrote:
>
>[ ... the Lai/Baker paper ... ]
>
>] But alternatively, one might wonder what's the point of writing
>] the metadata unless you're also writing the data that the metadata
>] is pointing to. If the synchonous metadata writes that some
>] filesystem provide will happily put the filesystem information down
>] but then defer the data writes for a later date, that information
>] is completely useless and possibly harmful, and it doesn't make any
>] difference whether it's written out by religious mandate or by the
>] elevator passing by that floor.
>
>
>That's an easy one to answer: so if you screw up, you *only*
>screw up the data that you are writing instead of screwing up
>all the data on the file system (or at least some of the data
>that was there before and totally uninvolved in the screwed
>transaction).
Now this is the point where I get interested. Could you describe how
sync metadata doesn't screw up unrelated data vs async metadata? (I'm
really interested in your analysis of this, since it's better than the
IS NOT! IS TOO! that this conversation has become.)
>It's a limitation on the amount of damage you can do.
My initial guess would be that sync metadata would increase the
window for corrupting data, because first you write the metadata,
then you go back and write the data; unless you've got a structure
where the metadata is at one end of the disk and the data is at the
other, it seems like it would average 1.5 passes over the platter
to write things out. Contrarily, if metadata and data is mixed
together, it will get dumped to disk in one pass, and even though
it's more likely you'll end up with data written and the metadata
not updated, it's all shovelled to disk faster.
____
david parsons \bi/ comp.filesystems.advocacy. I _really see
\/ a great need.