From owner-freebsd-hackers Fri Jan 10 14:07:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA05956 for hackers-outgoing; Fri, 10 Jan 1997 14:07:02 -0800 (PST) Received: from sumatra.americantv.com (sumatra.americantv.com [199.184.181.250]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA05949 for ; Fri, 10 Jan 1997 14:06:56 -0800 (PST) Received: from right.PCS (right.pcs. [148.105.10.31]) by sumatra.americantv.com (8.7.6/8.7.3) with ESMTP id QAA25875; Fri, 10 Jan 1997 16:05:24 -0600 (CST) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id WAA14513; Fri, 10 Jan 1997 22:06:37 GMT Message-ID: 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 References: <199701102006.NAA20414@phaeton.artisoft.com> X-Mailer: Mutt 0.56e Mime-Version: 1.0 In-Reply-To: <199701102006.NAA20414@phaeton.artisoft.com>; from Terry Lambert on Jan 10, 1997 13:06:51 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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