Multi-Grained Timestamps Submitted For Linux 6.6

[phoronix]

Phoronix: Multi-Grained Timestamps Submitted For Linux 6.6

In addition to the fchmodat2 system call, another early pull request submitted by Microsoft's Christian Brauner even before the Linux 6.5 kernel was released is one to introduce multi-grained timestamps with Linux 6.6. Multi-grained timestamps are intended to address an issue exhibited with NFS around caching and the current coarse-grained timestamp handling used for (in)validating caches...

https://www.phoronix.com/news/Multi-Grained-Timestamps

[geerge]

This sounds like one of those things that in a decade will be generally regarded as a bad move, but I'm not qualified enough to determine how much of a screw up MS is working on.

[skeevy420]

I prefer whole wheat timestamps.

I know nothing about this stuff. Is this something that matters if ATIME is off or if RELATIME is used?

[slalomsk8er]

This sounds like one of those things that in a decade will be generally regarded as a bad move, but I'm not qualified enough to determine how much of a screw up MS is working on.

Re purposing a bit in a field used for something else - what could go wrong?

[pepoluan]

Re purposing a bit in a field uses for something else - what could go wrong?

The field is defined as having the value in the range [0, 999999999]

That requires only 30 bits. 2 bits are unused.

[slalomsk8er]

The field is defined as having the value in the range [0, 999999999]

That requires only 30 bits. 2 bits are unused.

Maybe or maybe not - if you start pulling stunts like this, then there's no guaranties that you're the first

I hope, I read it right and they amend the standard so the next one with the same idea knows not to use the 31th but the 32th bit!

Anyways still smells like a hack.

[sophisticles]

This sounds like one of those things that in a decade will be generally regarded as a bad move, but I'm not qualified enough to determine how much of a screw up MS is working on.

Considering that all pull requests to the kernel have to be approved by Linus, if it is a screw up we will have Linus to thanks for it.

[coder]

I prefer whole wheat timestamps.

I know nothing about this stuff. Is this something that matters if ATIME is off or if RELATIME is used?

Unrelated.

Think about how client-side caching works. Here's a simple scenario.

Two machines, A & B, are both mounting a shared NFS volume from server S. Machine A is reading some files from the share and has them in a client-side cache (if you do this, NFS performance can be near native; if not, it generally sucks).

Now, machine B comes along and writes some of those files. For machine A to see the new modifications, the protocol needs to compare the versions A currently has in its cache and see that they're stale. I don't know on which end the timestamp comparison happens, but using low-granularity timestamps increases the chance that A is left looking at the old version of one or more files.

Now, as uncommon as this might sound, a lot of us use NFS for data-sharing. Specifically, I might be editing files from one client, maybe compiling them on another, and then testing them on a 3rd. All using the same, shared NFS volume. That's exactly the kind of use case they're addressing, here.

A more robust approach would be for the server to increment some kind of sequence number per file, each time it's modified. But, that would be a much bigger change to the protocol and increase resource usage on the server.

[timofonic]

Unrelated. Think about how client-side caching works. Here's a simple scenario. Two machines, A & B, are both mounting a shared NFS volume from server S. Machine A is reading some files from the share and has them in a client-side cache (if you do this, NFS performance can be near native; if not, it generally sucks). Now, machine B comes along and writes some of those files. For machine A to see the new modifications, the protocol needs to compare the versions A currently has in its cache and see that they're stale. I don't know on which end the timestamp comparison happens, but using low-granularity timestamps increases the chance that A is left looking at the old version of one or more files. Now, as uncommon as this might sound, a lot of us use NFS for data-sharing. Specifically, I might be editing files from one client, maybe compiling them on another, and then testing them on a 3rd. All using the same, shared NFS volume. That's exactly the kind of use case they're addressing, here. A more robust approach would be for the server to increment some kind of sequence number per file, each time it's modified. But, that would be a much bigger change to the protocol and increase resource usage on the server.

As you seem more savvy... Would this be a good approach? If not a developer, please a developer gives us some insight about this

[coder]

As you seem more savvy... Would this be a good approach? If not a developer, please a developer gives us some insight about this

I don't know exactly what you're referring to. Do you mean introducing the notion of sequence numbers to track file modifications?

I'm sure there's lots of complexity, lurking beneath the surface. One problem is how NFS servers appear to be stateless. This could mean that the server might have to persist these sequence numbers somewhere. The nice thing about timestamps is that filesystems already know what those are and have a place to store them.

BTW, I'm reminded of a configuration option I noticed, where Samba can apparently take advantage of some features in BTRFS. It would be neat if copy-on-write could somehow be used to solve this problem.

Anyway, I have no inside knowledge of NFS. So, take my comments as nothing more than idle speculation.