Date: Sat, 9 Dec 1995 07:58:56 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Cc: current@FreeBSD.org Subject: Re: POSIX compliance and time updates Message-ID: <199512082058.HAA11867@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512082058.HAA11867>