<div dir="ltr">We seem to be unsure whether or not the client is the one doing the atime updates. I don't really remember the details about NFS enough to know either, though my suspicion is that it's the server and not the client. Poking around at man pages, such as <a href="http://www.freebsd.org/cgi/man.cgi?query=mount_nfs&sektion=8">http://www.freebsd.org/cgi/man.cgi?query=mount_nfs&sektion=8</a> and <a href="http://linux.die.net/man/5/nfs">http://linux.die.net/man/5/nfs</a>, for example, there doesn't seem to be a "noatime" option for NFS mounts at all.<div>
<br></div><div>Since it hasn't been mentioned yet ... Have you tried doing a full packet capture and seeing just what is going on? Seems like it would be trivial to setup a "tcpdump -w /tmp/nfs host $name_of_server" on the client, then do the readonly mount, cat a small file, unmount, then verify if the atime was updated and take a look at what requests were made. You could then do the same thing but do a readonly,noatime mount, verify if there is different behavior, and see what is different in the packet capture.<div>
<br></div><div>I, too, would find it disturbing if the client is told to be read-only but it makes specific atime update requests. I would not find it disturbing that the server makes atime updates regardless of the client. I would find it strange that the client could influence the server on a per-mount basis.</div>
<div><br></div><div>fwiw, "readonly" mounts don't guarantee that the filesystem isn't going to be written to. It's standard for the OS to flush the journal/etc when mounting regardless of readonly status. For example:</div>
<div><br></div><div><a href="https://www.kernel.org/doc/Documentation/filesystems/ext4.txt">https://www.kernel.org/doc/Documentation/filesystems/ext4.txt</a><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><font face="courier new, monospace">[...]</font></div><div><div><font face="courier new, monospace">When mounting an ext4 filesystem, the following option are accepted:</font></div></div><div><div><font face="courier new, monospace">ro <span class="" style="white-space:pre"> </span>Mount filesystem read only. Note that ext4 will</font></div>
</div><div><div><font face="courier new, monospace"> <span class="" style="white-space:pre"> </span>replay the journal (and thus write to the</font></div></div><div><div><font face="courier new, monospace"> <span class="" style="white-space:pre"> </span>partition) even when mounted "read only". The</font></div>
</div><div><div><font face="courier new, monospace"> <span class="" style="white-space:pre"> </span>mount options "ro,noload" can be used to prevent</font></div></div><div><div><font face="courier new, monospace"><span class="" style="white-space:pre"> </span> <span class="" style="white-space:pre"> </span>writes to the filesystem.</font></div>
</div><div><font face="courier new, monospace">[...]</font></div></blockquote><div><br></div><div>Also fwiw, the older version of TR-3183 from NetApp (<a href="http://olug.org/presentations/March2005/nfs.pdf">http://olug.org/presentations/March2005/nfs.pdf</a>, Using the Linux NFS Client with Network Appliance Filers) has a section that says:</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="courier new, monospace">[...]</font></div><div><div><font face="courier new, monospace">It is a common trick for system administrators to use the “noatime” mount option on local file systems to </font><span style="font-family:'courier new',monospace">improve overall file system performance by preventing a synchronous metadata update every time a </span><span style="font-family:'courier new',monospace">file is accessed in some way. Because NFS servers, not clients, control the values contained in a file’s </span><span style="font-family:'courier new',monospace">timestamps (access time, metadata change time, and data modify time) by default, this trick is not </span><span style="font-family:'courier new',monospace">effective for NFS mounts. However, filers allow you to reduce the overhead caused by aggressive </span><span style="font-family:'courier new',monospace">atime flushing if you set a volume’s no_atime_update option. On a filer console, type “help vol </span><span style="font-family:'courier new',monospace">options” for details. </span></div>
</div><div><font face="courier new, monospace">[...]</font></div></blockquote><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 7, 2013 at 2:24 PM, Dean Anderson <span dir="ltr"><<a href="mailto:dean@av8.com" target="_blank">dean@av8.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi folks,<br>
<br>
Its been a while. I've been lurking tho.<br>
<br>
There is no mystery: The nfs server itself doesn't have the filesystem<br>
mounted read-only. So the client should respect the RO on nfs mount.<br>
However, actually reading the file causes the nfs server itself to<br>
access the file, and since that system isn't mounting its own disk read<br>
only, it updates atime--as it should.<br>
<br>
Try mounting the exported filesystem readonly on the filesever and see<br>
what happens...<br>
<br>
--Dean<br>
<div class="im"><br>
On Dec 4, 2013, at 10:37 PM, Alex Aminoff <<a href="mailto:alex@basespace.net">alex@basespace.net</a>> wrote:<br>
<br>
On 12/4/2013 10:21 PM, Matt Simmons wrote:<br>
My knowledge is somewhat limited to the Linux world, but in my<br>
experience I've never seen a mount be set to 'ro' and have anything<br>
updated. I hate to use the term 'flabbergasted', but I'm pretty sure<br>
that if I saw an implementation that didn't respect the 'ro' flag, I'd<br>
be at the very least 'put out', and perhaps even vitriolic.<br>
<br>
Yeah, flabbergasted is a good description of how I felt.<br>
<br>
</div><div class="im">Nevertheless, I tested it and unless I messed up my test, an NFS mount<br>
with -o ro, you read a file on the mounted FS, and the access time is<br>
updated.<br>
<br>
</div><div><div class="h5">For the test the server was a NetApp, the client was Linux.<br>
<br>
There is a mount flag -o noatime that does what I want. But I would<br>
argue that this is not right. The simplest behavior - nothing is ever<br>
written period - should be what you get by default, and then there could<br>
be a flag that enables exceptional behavior, that is updating the access<br>
time.<br>
<br>
I can squint and see why it would be the way it is. One perspective is<br>
that the naive assumption is that reading off a RO filesystem should be<br>
just like reading any other way; when you read, the OS conveniently<br>
remembers when you did. The inconsistency of "writing" to a read-only<br>
thing is less important than the inconsistency of not updating the<br>
access time when the file is read.<br>
<br>
But what if the underlying device is not capable of recording access<br>
times, like a CD-ROM? Can you look at the mount options and see that a<br>
CDROM is read-only? But then you can't know whether access times will be<br>
updated unless you use some other method to find out what the underlying<br>
device is. So that's an abstraction violation. Bother, I don't have a<br>
unix box easily to hand where I can check what the mount options on a<br>
CDROM look like.<br>
<br>
I'm not sure if this is just grousing, or flame bait, or a gotcha that<br>
every sysadmin should know because there is no way to anticipate it.<br>
<br>
- Alex<br>
<br>
--Matt<br>
<br>
<br>
<br>
On Tue, Dec 3, 2013 at 2:21 PM, Alex Aminoff <<a href="mailto:alex@basespace.net">alex@basespace.net</a><br>
<mailto:<a href="mailto:alex@basespace.net">alex@basespace.net</a>>> wrote:<br>
<br>
<br>
Hi folks. I encountered something odd.<br>
<br>
Suppose you mount a file system read only. You read a file from<br>
it. Does<br>
the access time of that file get updated?<br>
<br>
In one place I found documentation saying no. But other places seem to<br>
imply that it does.<br>
<br>
Does the answer change if it is an NFS mount?<br>
<br>
I have deliberately left details of what OS I'm using out, because it<br>
seems to me that the answer should be consistent, and if it is not, it<br>
should be documented publicly.<br>
<br>
- Alex Aminoff<br>
BaseSpace.net, NBER<br>
<br>
<br>
<br>
<br>
</div></div> _______________________________________________<br>
bblisa mailing list<br>
<div class="im HOEnZb"> <a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a> <mailto:<a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a>><br>
<a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br>
<br>
<br>
<br>
<br>
--<br>
"Today, vegetables... Tomorrow, the world!"<br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
bblisa mailing list<br>
<a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a><br>
<a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br>
<br>
_______________________________________________<br>
bblisa mailing list<br>
<a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a><br>
<a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br>
<br>
_______________________________________________<br>
bblisa mailing list<br>
<a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a><br>
<a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br>
</div></div></blockquote></div><br></div>