Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!howland.reston.ans.net!newsjunkie.ans.net!newsfeeds.ans.net!venger.snds.com!hill.ucr.edu!grif From: grif@hill.ucr.edu (Michael Griffith) Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux Date: 11 Feb 1996 03:39:28 GMT Organization: UC Riverside, Dept. of Computer Science Lines: 67 Message-ID: <4fjodg$o8k@venger.snds.com> References: <4er9hp$5ng@orb.direct.ca> <4f9skh$2og@dyson.iquest.net> <4fg8fe$j9i@pell.pell.chi.il.us> <311C5EB4.2F1CF0FB@freebsd.org> NNTP-Posting-Host: hill.ucr.edu Cc: Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:13588 comp.os.linux.development.system:17087 In article <311C5EB4.2F1CF0FB@freebsd.org>, Jordan K. Hubbard <jkh@FreeBSD.org> wrote: |Orc wrote: |> No, this isn't a Linux vs FreeBSD debate, though it's certainly |> one of the things that makes FreeBSD less attractive for my news |> machine; I keep people one one side stating that writing metadata | |So why not simply run 2.1-STABLE or 2.2-CURRENT, where the async flag is |honored for filesystems? | |If you want to see it in action, simply install the 2.2-960130-SNAP |(available from ftp://ftp.freebsd.org/pub/FreeBSD/) and watch how much |faster the installations are extracted. Cool. It should be the new default. |I don't think that the async-vs-sync metadata write issues are worth |debating since the whole topic is truly too subjective for meaningful |discussion. I fail to see how it is subjective. |I would suggest instead simply trying sync vs async on your own system, |being as (in)cautious as you care to be in the transition, and then post |your experiences. People need concrete evidence here, not abstract |debate. How about a proof? Claim: Writing metadata synchronously and data asynchronously can put a filesystem in a state that has undetectable errors. Proof: Given, * A metadata item (inode) M that initially references no data blocks. * Data blocks D0 .. DN with random (junk) values. * Buffer cache equivalents of D0 .. DN, D0' .. DN'. We assume (in proceeding toward a contradiction) that writing sync meta and async data can never leave a filesystem in a state where it has undetectable errors. Perform a sync metadata and async data update on M. In memory, the contents of D0' .. DN' are updated to new values. On disk, M is synchronously (immediately) updated to refer to D0 .. DN. Turn off the power before D0' .. DN' can be asynchronously (lazily) written back do replace D0 .. DN on disk. The in-memory content of D0' .. DN' are lost and the old on-disk values D0 .. DN remain. M now references old (junk) values in D0 .. DN. Because the contents of D0 .. DN are indistinguishable from the contents of D0' .. DN', the filesystem has produced an undetectable error. We have reached a contradiction. Therefore the assumption is false and claim holds. -- Michael A. Griffith (grif@cs.ucr.edu) | http://www.cs.ucr.edu/~grif/ Department of Computer Science | PGP public key available. University of California, Riverside | "My freedom of speech implies (909) 787-3803 | your freedom to be offended."