Multi-Grained Timestamps Submitted For Linux 6.6

[xnor]

Tracking changes solely through timestamps is a bad technical choice since there almost always will be ambiguity.
One should pick a timestamp with as few bits as needed and use a revision/version counter to track changes "during" the same timestamp value.

Additionally, storing many timestamps based on a set-in-stone epoch (like unix time) is also wasteful. If you can spare an extra addition per timestamp (while saving some bits) then it makes more sense to store offsets from a "creation timestamp".

[coder]

Tracking changes solely through timestamps is a bad technical choice since there almost always will be ambiguity.
One should pick a timestamp with as few bits as needed and use a revision/version counter to track changes "during" the same timestamp value.

That would require the filesystem to support atomic read-modify-write of the file metadata. I'm not sure all filesystems would let you do that. Normal updates to the file MTime are simple writes.

Additionally, storing many timestamps based on a set-in-stone epoch (like unix time) is also wasteful. If you can spare an extra addition per timestamp (while saving some bits) then it makes more sense to store offsets from a "creation timestamp".

No matter what NFS does, the filesystems themselves tend to allocate a full 64 or 96 bits for the timestamp. Maybe it would've been considered wasteful like 30 years ago, but considering the amount of space that modern filesystems allocate for metadata -- not to mention 4k block sizes -- storing a full 8 or 12 bytes for each timestamp isn't a big deal.

If you want a good bone to pick with UNIX filesystems, it'd have to be ATime. I always use the noatime mount attribute. ATime is pretty dumb, not to mention a waste of space.

[xnor]

That would require the filesystem to support atomic read-modify-write of the file metadata. I'm not sure all filesystems would let you do that. Normal updates to the file MTime are simple writes.

Are you saying that there are data races in file system metadata handling? I don't think so.
Writing a smaller timestamp and revision/version counter is still a simple write. The only difference is that instead of writing an ambiguous timestamp you write a smaller timestamp followed by a small counter that indicates the total writes during the timestamp.
This is far superior than the proposed Multi-Grained Timestamp patch, which just temporarily increases timestamp granularity to reduce (but not necessarily eliminate) this loss of information.

No matter what NFS does, the filesystems themselves tend to allocate a full 64 or 96 bits for the timestamp. Maybe it would've been considered wasteful like 30 years ago, but considering the amount of space that modern filesystems allocate for metadata -- not to mention 4k block sizes -- storing a full 8 or 12 bytes for each timestamp isn't a big deal.

If you want a good bone to pick with UNIX filesystems, it'd have to be ATime. I always use the noatime mount attribute. ATime is pretty dumb, not to mention a waste of space.

Huh, any number of bits you can safe means you can store metadata for more files in a single block.
In ext3 an inode used 128 bytes. Extended timestamps needlessly take up a lot of bytes. In ext4 inodes are now written in chunks of 256 bytes which halves the number of file metadata you can store in a block.