File timestamp granularity in *nix file systems

Topic

New Reply

I am probably pushing my luck here, but I have been unable to find hard information about what is the file timestamp granularity on any of the *nix-based file systems, like ext, ext2, ext3, ext4, Reiser and the like.

All us Microsoft chaps know that the timestamp granularity of files in the various file systems is as follows:
FAT – 2 seconds
exFAT – 10 milliseconds
NTFS – 100 nanoseconds

All I can find is the unverified statement that
“Linux with ext2/ext3 has 1-second timestamp granularity”.

There are two separate issues here as well:
* the resolution of the file timestamps held on the hard disk directory/index/whatever
* the resolution of the file timestamps reported to user programs (like backup)

Why do I care about this? My recently-acquired NAS (believed to run under Xenix) gives the appearance of being formatted with NTFS but in practice it does not seem to return the NTFS timestamp resolution. If you compare the timestamps of the same file held on a ‘real’ NTFS system with that on the NAS, they can be different by 2 or (rarely) more seconds. This difference is important when you are trying to copy only ‘changed’ files from a ‘real’ NTFS disk to the NAS, because most of the time the same file will appear to be up to a couple of seconds older on the NAS, so a copy will usually be scheduled to take place even though the content of the files is identical. With ROBOCOPY, for example, you have to specify the /FFT option, which means “consider source and target files to be identical if their timestamps differ by 2 seconds or less”, and even then there will still be some files copied (because the source file is thought to be newer) even though I’m petty certain they are the same file.

Some stats for your amusement, for identical copies:

Code:

Without /FFT switch
				Total	  Copied	 Skipped
	Files :	573566	  184068	  389498
	Bytes :   244.405 GB  161.705 GB   82.700 GB

With /FFT switch 
				Total	  Copied	 Skipped
	Files :	573566	   14382	  559184
	Bytes :   244.405 GB   31.816 GB  212.589 GB

Has anyone done any work in this area?

BATcher

Plethora means a lot to me.

Reply | Quote

Replies

I may be late to respond to this, but it’s because I just found out about this forum today and this is the first time I’m browsing through it.

Anyhow, since nobody has responded to this I’ll post a comment.

All UNIX/Linux filesystems historically use a 1 second resolution timestamp, that is until just recently with the new ext4 filesystem, which uses a 1 nanosecond timestamp.

A pretty good reference –> http://www.ibm.com/developerworks/linux/library/l-anatomy-ext4/

But even though ext4 meets your needs, Samba does not because it will still use the 1 second resolution, at least until it gets updated for this, if ever.

Reply | Quote

I was trying to do the exact same thing as BATcher and ran into the same problem. I was using Java to write my backup program which provides the time in units of msecs, so I logged the source and target times. I was getting things like source time = nnnnnnnnn383 and target time = nnnnnnnnn000. There you go, resolution of seconds from my NAS. So I just coded my condition to replace a file as IF (sourceTm > (targetTm + 999)) and got the desired behavior.

Why didn’t EVERY file appear to need replacement? I had recently replaced my computer and populated its hard drive from the NAS where the backups had previously been done by hand.

Reply | Quote