Hi-
It was recently pointed out to me that the behavior of atime on NFS mount points is pretty dodgy, yet this is not documented anywhere, not even in the venerable and unmaintained Linux NFS FAQ.
A good place to cover this topic might be nfs(5). It could discuss how the Linux NFS client deals with the various *atime mount options (mostly be collapsing them into relatime, all the time). And it could discuss how file timestamps are updated when the physical backing store is on another system.
Thoughts? Comments?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Mon, 2013-11-11 at 15:35 -0500, Chuck Lever wrote:
+AD4- On Nov 11, 2013, at 12:33 PM, +ACI-Myklebust, Trond+ACI- +ADw-Trond.Myklebust+AEA-netapp.com+AD4- wrote:
+AD4-
+AD4- +AD4-
+AD4- +AD4- On Nov 11, 2013, at 11:50, Chuck Lever +ADw-chuck.lever+AEA-oracle.com+AD4- wrote:
+AD4- +AD4-
+AD4- +AD4APg- Hi-
+AD4- +AD4APg-
+AD4- +AD4APg- It was recently pointed out to me that the behavior of atime on NFS mount points is pretty dodgy, yet this is not documented anywhere, not even in the venerable and unmaintained Linux NFS FAQ.
+AD4- +AD4APg-
+AD4- +AD4APg- A good place to cover this topic might be nfs(5). It could discuss how the Linux NFS client deals with the various +ACo-atime mount options (mostly be collapsing them into relatime, all the time). And it could discuss how file timestamps are updated when the physical backing store is on another system.
+AD4- +AD4APg-
+AD4- +AD4APg- Thoughts? Comments?
+AD4- +AD4-
+AD4- +AD4- NFS atime is not the same as relatime.
+AD4- +AD4-
+AD4- +AD4- Our atime is only updated when a READ rpc call goes to the server. Cached reads do not, for instance, trigger an atime update. That is a very different model than the relatime model.
+AD4-
+AD4- Yes, but /proc/mounts shows the +ACI-relatime+ACI- option on NFS mounts. And apparently it doesn't go away if you specify +ACI-noatime,+ACI- for example.
+AD4-
+AD4- Basically it looks to some people like NFS ignores all the atime mount options. We should document how NFS behaves, or fix it.
We +AF8-should+AF8- ignore all atime mount options.
I'm fine with documenting the behaviour somewhere, but my point was that
documenting it in terms of +ACI-relatime+ACI- is not correct. We could, however,
clear that default MNT+AF8-RELATIME flag that 'do+AF8-mount' conveniently sets
for us.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust+AEA-netapp.com
http://www.netapp.com
On Nov 11, 2013, at 4:02 PM, "Myklebust, Trond" <[email protected]> wrote:
> On Mon, 2013-11-11 at 15:35 -0500, Chuck Lever wrote:
>> On Nov 11, 2013, at 12:33 PM, "Myklebust, Trond" <[email protected]> wrote:
>>
>>>
>>> On Nov 11, 2013, at 11:50, Chuck Lever <[email protected]> wrote:
>>>
>>>> Hi-
>>>>
>>>> It was recently pointed out to me that the behavior of atime on NFS mount points is pretty dodgy, yet this is not documented anywhere, not even in the venerable and unmaintained Linux NFS FAQ.
>>>>
>>>> A good place to cover this topic might be nfs(5). It could discuss how the Linux NFS client deals with the various *atime mount options (mostly be collapsing them into relatime, all the time). And it could discuss how file timestamps are updated when the physical backing store is on another system.
>>>>
>>>> Thoughts? Comments?
>>>
>>> NFS atime is not the same as relatime.
>>>
>>> Our atime is only updated when a READ rpc call goes to the server. Cached reads do not, for instance, trigger an atime update. That is a very different model than the relatime model.
>>
>> Yes, but /proc/mounts shows the "relatime" option on NFS mounts. And apparently it doesn't go away if you specify "noatime," for example.
>>
>> Basically it looks to some people like NFS ignores all the atime mount options. We should document how NFS behaves, or fix it.
>
> We _should_ ignore all atime mount options.
Makes sense.
> I'm fine with documenting the behaviour somewhere, but my point was that
> documenting it in terms of "relatime" is not correct. We could, however,
> clear that default MNT_RELATIME flag that 'do_mount' conveniently sets
> for us.
I'm operating from what users can observe, and they see "relatime" in /proc/mounts, which is why I described it that way. /proc/mounts is clearly wrong, then.
Can you make the kernel work the way you prefer? I'm happy to provide an update to nfs(5) that documents that preference. I think we do need to discuss how timestamps work on NFS, and exactly what happens when "*atime" mount options are specified.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Nov 11, 2013, at 11:50, Chuck Lever <[email protected]> wrote:
> Hi-
>
> It was recently pointed out to me that the behavior of atime on NFS mount points is pretty dodgy, yet this is not documented anywhere, not even in the venerable and unmaintained Linux NFS FAQ.
>
> A good place to cover this topic might be nfs(5). It could discuss how the Linux NFS client deals with the various *atime mount options (mostly be collapsing them into relatime, all the time). And it could discuss how file timestamps are updated when the physical backing store is on another system.
>
> Thoughts? Comments?
NFS atime is not the same as relatime.
Our atime is only updated when a READ rpc call goes to the server. Cached reads do not, for instance, trigger an atime update. That is a very different model than the relatime model.
Cheers
Trond
On Nov 11, 2013, at 12:33 PM, "Myklebust, Trond" <[email protected]> wrote:
>
> On Nov 11, 2013, at 11:50, Chuck Lever <[email protected]> wrote:
>
>> Hi-
>>
>> It was recently pointed out to me that the behavior of atime on NFS mount points is pretty dodgy, yet this is not documented anywhere, not even in the venerable and unmaintained Linux NFS FAQ.
>>
>> A good place to cover this topic might be nfs(5). It could discuss how the Linux NFS client deals with the various *atime mount options (mostly be collapsing them into relatime, all the time). And it could discuss how file timestamps are updated when the physical backing store is on another system.
>>
>> Thoughts? Comments?
>
> NFS atime is not the same as relatime.
>
> Our atime is only updated when a READ rpc call goes to the server. Cached reads do not, for instance, trigger an atime update. That is a very different model than the relatime model.
Yes, but /proc/mounts shows the "relatime" option on NFS mounts. And apparently it doesn't go away if you specify "noatime," for example.
Basically it looks to some people like NFS ignores all the atime mount options. We should document how NFS behaves, or fix it.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com