Re: [RFC] nanoseconds vs. the epoch

Peter Staubach wrote:
> Alexandre Ratchov wrote:
> >IMHO, having a global (per host) serial number that is incremented at
> >each file system operation could solve most of these issues.
> 
> This serial number, ala the generation count which was added for NFS,
> would certainly have addressed the "has the file changed" issue, if it
> had been added 20+ years ago.  Now, there is no support in the NFS
> protocols for such.  Support could be added to a future revision of
> the NFSv4 protocol, but that is quite some time away.

No, what Alexandre describes is exactly what NFSv4 already depends on
for cache revalidation; see the description of the "change" attribute
under section 5.5 of rfc3530:

	"A value created by the server that the client can use to
	determine if file data, directory contents or attributes of the
	object have been modified.  The server may return the object's
	time_metadata attribute for this attribute's value but only if
	the filesystem object can not be updated more frequently than
	the resolution of time_metadata."

This is a 64-bit value, and is a mandatory, per-file attribute.

So really what we want is something that's guaranteed to change with
each filesystem operation.  Increasing timestamp resolution won't do
that on its own.  For example, running the appended test program on my
laptop, on an xfs filesystem, produces the following output:

bfields@puzzle:xfs$ ~/projects/test/test_ctime
success
before mkdir: ctime:1144116895.55622681
              mtime:1144116895.55622681
after mkdir:  ctime:1147959633.236545203
              mtime:1147959633.236545203
after rmdir:  ctime:1147959633.236545203
              mtime:1147959633.236545203

So even though xfs has nanosecond-resolution times, the ctime and mtime don't
change after the rmdir, I suppose because the actual timesource is something
lower-resolution like jiffies.

I can see the same problem on a loopback-mounted nfsv4 export of an xfs
filesystem, though only intermittently.  I don't think I've reproduced it over
a real network, but I also haven't tried very hard.

Since the point of ctime, for many users (not just nfs), is to actually find
out whether a file has changed, it would seem very useful to have a something
that was actually *guaranteed* to act like a real change attribute.

--b.

#include <stdio.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
	int ret;
	struct stat stat1, stat2, stat3;
	int delay;

	switch (argc) {
		case 1:
			delay = 0;
			break;
		case 2:
			delay = atoi(argv[1]);
			break;
		default:
			errx(1, "usage: %s [delay in microseconds]\n", argv[0]);
	}
	ret = stat(".", &stat1);
	if (ret)
		err(1, "stat1");

	ret = mkdir("testdir", 0x777);
	if (ret)
		err(1, "mkdir");
	ret = stat(".", &stat2);
	if (ret)
		err(1, "stat2");

	if (delay)
		usleep(delay);

	ret = rmdir("testdir");
	if (ret)
		err(1, "unlink");
	ret = stat(".", &stat3);
	if (ret)
		err(1, "stat3");

	printf("success\n");
	printf("before mkdir: ctime:%d.%ld\n", stat1.st_ctim.tv_sec,
					       stat1.st_ctim.tv_nsec);
	printf("              mtime:%d.%ld\n", stat1.st_mtim.tv_sec,
					       stat1.st_mtim.tv_nsec);
	printf("after mkdir:  ctime:%d.%ld\n", stat2.st_ctim.tv_sec,
					       stat2.st_ctim.tv_nsec);
	printf("              mtime:%d.%ld\n", stat2.st_mtim.tv_sec,
					       stat2.st_mtim.tv_nsec);
	printf("after rmdir:  ctime:%d.%ld\n", stat3.st_ctim.tv_sec,
					       stat3.st_ctim.tv_nsec);
	printf("              mtime:%d.%ld\n", stat3.st_mtim.tv_sec,
					       stat3.st_mtim.tv_nsec);
	exit(0);
}