From owner-freebsd-hackers  Tue Mar 11 01:46:35 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id BAA09812
          for hackers-outgoing; Tue, 11 Mar 1997 01:46:35 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA09806
          for <freebsd-hackers@FreeBSD.ORG>; Tue, 11 Mar 1997 01:46:31 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id UAA06877; Tue, 11 Mar 1997 20:36:30 +1100
Date: Tue, 11 Mar 1997 20:36:30 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199703110936.UAA06877@godzilla.zeta.org.au>
To: bde@zeta.org.au, terry@lambert.org
Subject: Re: Hard Link Count too small!
Cc: freebsd-hackers@FreeBSD.ORG, jez@netcraft.co.uk
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>> >> I have some POSIX performance tests that do this several times.  They
>> >> take too long.  They take much too long if the filesystem is not async
>> >> mounted.
>> >
>> >They must not be very POSIX dependent, or they would fail from the
>> >"shall mark for update"/"shall update" discrepancies introduced by
>> >the async mount.  An async mounted FS is not POSIX compliant.  An
>> 
>> Wrong.
>
>"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.

Bruce