Date: Tue, 11 Mar 1997 10:49:24 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, terry@lambert.org, freebsd-hackers@freebsd.org, jez@netcraft.co.uk Subject: Re: Hard Link Count too small! Message-ID: <199703111749.KAA25596@phaeton.artisoft.com> In-Reply-To: <199703110936.UAA06877@godzilla.zeta.org.au> from "Bruce Evans" at Mar 11, 97 08:36:30 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >"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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703111749.KAA25596>