From owner-freebsd-hackers Tue Mar 11 14:04:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA13410 for hackers-outgoing; Tue, 11 Mar 1997 14:04:54 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA13394 for ; Tue, 11 Mar 1997 14:04:49 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA26178; Tue, 11 Mar 1997 14:55:41 -0700 From: Terry Lambert Message-Id: <199703112155.OAA26178@phaeton.artisoft.com> Subject: Re: Hard Link Count too small! To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 11 Mar 1997 14:55:41 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <19970311202555.KX24648@uriah.heep.sax.de> from "J Wunsch" at Mar 11, 97 08:25:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Yes. And this is what must be prevented. POSIX compliance must be > > maintained by stable storage, ... > > So any system without RAID would be in danger of losing POSIX > compliance under some circumstances. Only if you refuse to provide atomicity for non-idempotent operations against the FS. Like if you mount the thing -async. Otherwise, it is deterministically recoverable to the correct state, as mandated by POSIX, since it is done one-behind. The VIVA FS papers provide a wonderful study of the application of idempotence requirements in the context of the POSIX standards. There is a potential disconnect in the soft updates case for any system (like FreeBSD) which unifies the VM and buffer cache. For those systems, soft updates will degrade to DOW performance in order to make the guarantees, unless soft updates are implemented at the FS/BIO (in the FreeBSD case, FS/VM) interaction layer instead of in the FS proper. This is pretty obvious from the Ganger/Patt paper, for what it's worth. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.