From owner-freebsd-hackers Tue Mar 11 09:57:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA25036 for hackers-outgoing; Tue, 11 Mar 1997 09:57:30 -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 JAA24994 for ; Tue, 11 Mar 1997 09:57:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA25596; Tue, 11 Mar 1997 10:49:24 -0700 From: Terry Lambert Message-Id: <199703111749.KAA25596@phaeton.artisoft.com> Subject: Re: Hard Link Count too small! To: bde@zeta.org.au (Bruce Evans) Date: Tue, 11 Mar 1997 10:49:24 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, freebsd-hackers@freebsd.org, jez@netcraft.co.uk In-Reply-To: <199703110936.UAA06877@godzilla.zeta.org.au> from "Bruce Evans" at Mar 11, 97 08:36:30 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 > >"SHALL BE UPDATED". > > > >Not "SHALL BE WRITTEN TO CACHE AND MAYBE UPDATED SOMETIME". > > Right. Updating consists of converting a mark (which is usually > implemented as a single bit, e.g., IN_ACCESS in ufs) to a time. This has > nothing to do with caching. POSIX does not specify storage in RAM, > disks, paper tape or stone tablets - these are implementation details. > The system may simply cease to be POSIX conformant when the system crashes > or the storage fails. Yes. And this is what must be prevented. POSIX compliance must be maintained by stable storage, either through ordering of operations (no -async) and post-crash repair (fsck), OR through some other mechanism (alternate ordering mechanisms, or mechanisms using some form of transactioning/logging/journalling) to allow the repair to proceed deterministically. And thereby maintain compliance. It is not acceptable to modify a block in a file, and not have the modification time stamp adjusted. This is a possible occurance in the "-async" mode, and will happen if another modification is made, resetting the queue position of the time stamp write but not of the data block write. Alternately, write reordering could cause it to occur with a single operation, which must update a pair of locations. Finally, a two stage commit on a database consisting of a file and an index requires that the file data be written reliably before the index data. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.