From owner-freebsd-current Fri Dec 8 13:02:12 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA21720 for current-outgoing; Fri, 8 Dec 1995 13:02:12 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA21694 for ; Fri, 8 Dec 1995 13:01:58 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA11867; Sat, 9 Dec 1995 07:58:56 +1100 Date: Sat, 9 Dec 1995 07:58:56 +1100 From: Bruce Evans Message-Id: <199512082058.HAA11867@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: POSIX compliance and time updates Cc: current@FreeBSD.org Sender: owner-current@FreeBSD.org Precedence: bulk >> >should be: >> >> > error = VOP_UPDATE(vp, &atimeval, &mtimeval, 0); >> >> I've been running with this change for years. It is just an >> optimization and is only wrong if the system crashes. My comment about >> it says that it is stupid to update times synchronously but not update >> ids and permissions synchronously. >I actually have someone here in the wings who is willing to get into a >flame war on POSIX "should/shall/may" arguing that POSIX does not >require an immediate update here by virtue of the exact wording. POSIX specifies marking for update and update of file times, not recording these updates on eternal storage! For utime(NULL), it specifies setting the atime and the mtime to the current time and marking for update the ctime. The ctime need not be updated until the next close or [f]stat, so if the file is held open and not stat'ed for several years, the apparent ctime may be several years later than the actual ctime. >> >This should significantly increase performance on the bogus create/delete >> >benchmark. Actually, ufs_setattr() isn't called for creat/close/unlink so improving it wouldn't affect the benchmark. You need a sillier benchmark to demonstrate extreme slowness, e.g., `find / | xargs touch'. >> The performance is still low. 100 creat/unlink's take >> >> 5.01 real 0.01 user 0.14 sys >> >> here. They should take about 0.15 real (33 times faster). >"should"? You mean "do on Linux", not "should", right? 8-). No, I mean that it should take 0.15 sec with reliable (not semi-random async) updates. Something involving delayed writes. If the writes are delayed for > 0.15 seconds then the need to write goes away. Bruce