Date: Fri, 10 Jan 1997 16:06:36 -0600 From: jlemon@americantv.com (Jonathan Lemon) To: terry@lambert.org (Terry Lambert) Cc: scrappy@hub.org (The Hermit Hacker), hackers@freebsd.org Subject: Re: mount -o async on a news servre Message-ID: <Mutt.19970110160636.jlemon@right.PCS> In-Reply-To: <199701102006.NAA20414@phaeton.artisoft.com>; from Terry Lambert on Jan 10, 1997 13:06:51 -0700 References: <Pine.BSF.3.95.970110065253.5112P-100000@thelab.hub.org> <199701102006.NAA20414@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > Effectively, this means ordering the writes. There are a number > of ways to do this: > > o Order them explicitly by doing async writes to stable > cache. This requires specialized hardware and is not a > generic soloution. Sun's PrestoServe hardware does this; > so do Auspex NFS servers. You would be hard put to find PC > controllers even capable of this, let alone drivers that > could handle it. The BIO subsystem would require significant > changes to be able to put stable commit incursions up to > the point an FS could choose between a stable commit to > cache, a stable commit to disk, and an unstable commit to disk > (a necessary optimization for non-metadata data originating > locally instead of as the result of a network transaction). > This is an OK, if very expensive, way to implement a good thing. Another possibility is illustrated in a recent ASPLOS paper on robustness in the face of operating system crashes. IIRC, their system (Petal?) has the entire DRAM on a battery backup, and after a crash/reboot, a diagnostic utility goes through memory and writes out any pending data buffers. I'm not convinced that this would really increase reliability; most problems are usually hardware/power supply based; not OS crashes. -- Jonathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970110160636.jlemon>