It wasn&#39;t so much eaten by spam filters as &quot;contained the word POSIX so everyone&#39;s eyes glazed over and we went into comas&quot; :)<br><br><div>On Fri Dec 06 2013 at 1:14:48 PM, Dave Allan &lt;<a href="mailto:dave@dpallan.com">dave@dpallan.com</a>&gt; wrote:</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Dec 06, 2013 at 09:36:01AM -0500, John Stoffel wrote:<br>
&gt; &gt;&gt;&gt;&gt;&gt; &quot;John&quot; == John P Rouillard &lt;<a href="mailto:rouilj@cs.umb.edu" target="_blank">rouilj@cs.umb.edu</a>&gt; writes:<br>
&gt;<br>
&gt; John&gt; In message<br>
&gt; John&gt; &lt;CAJFsZ=<a href="mailto:oBBwr7n_1BcJBO2e-DHJrQWp8mxGEU4tADmBkWz1Bdfw@mail.gmail.com" target="_blank">oBBwr7n_1BcJBO2e-<u></u>DHJrQWp8mxGEU4tADmBkWz1Bdfw@<u></u>mail.gmail.com</a>&gt; ,<br>
&gt; John&gt; Bill Bogstad writes:<br>
&gt; &gt;&gt; On Thu, Dec 5, 2013 at 10:03 AM, Edward Ned Harvey (bblisa4)<br>
&gt; &gt;&gt; &lt;<a href="mailto:bblisa4@nedharvey.com" target="_blank">bblisa4@nedharvey.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt;&gt; From: <a href="mailto:bblisa-bounces@bblisa.org" target="_blank">bblisa-bounces@bblisa.org</a> [mailto:<a href="mailto:bblisa-bounces@bblisa.org" target="_blank">bblisa-bounces@bblisa.<u></u>org</a>] On<br>

&gt; &gt;&gt;&gt;&gt; Behalf Of Alex Aminoff<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; Nevertheless, I tested it and unless I messed up my test, an NFS mount<br>
&gt; &gt;&gt;&gt;&gt; with -o ro, you read a file on the mounted FS, and the access time is<br>
&gt; &gt;&gt;&gt;&gt; updated.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Oh - that could explain it right there -<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; I think the client isn&#39;t the one doing the update.  I think your<br>
&gt; &gt;&gt;&gt; server is updating the last access time on the file, because the<br>
&gt; &gt;&gt;&gt; server served the file to the client.  The server doesn&#39;t<br>
&gt; &gt;&gt;&gt; necessarily know you mounted read-only<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; That makes a lot of sense.   Alex doesn&#39;t say what version of the NFS<br>
&gt; &gt;&gt; protocol he is using, but a quick check of the RFC for the MOUNT<br>
&gt; &gt;&gt; protocol for NFSv3 (see page 105 for mount protocol<br>
&gt; &gt;&gt; <a href="http://www.ietf.org/rfc/rfc1813.txt" target="_blank">http://www.ietf.org/rfc/<u></u>rfc1813.txt</a>) doesn&#39;t seem to give a way for a<br>
&gt; &gt;&gt; client to indicate that it wants to mount a filesystem as readonly.<br>
&gt; &gt;&gt; Maybe someone who is more familiar with the NFS protocol can confirm<br>
&gt; &gt;&gt; this.<br>
&gt;<br>
&gt; John&gt; That is my understanding as well.<br>
&gt;<br>
&gt; John&gt; Also mounting a filesystem ro IIRC used to change some metadata<br>
&gt; John&gt; in the filesystem. Maybe last mount time, number of times<br>
&gt; John&gt; mounted ... depending on the FS type.<br>
&gt;<br>
&gt; John&gt; I know from forensics work there can be a bunch of things that<br>
&gt; John&gt; will change the filesystem/disk state. Hence most forensics<br>
&gt; John&gt; people:<br>
&gt;<br>
&gt; John&gt;   1) use a hardware rig that will NOT issue write commands to the<br>
&gt; John&gt;      source disk to copy the source disk to a disk they will use<br>
&gt; John&gt;      for investigation.<br>
&gt; John&gt;   2) use tools that are designed to not mess up the filesystem in the<br>
&gt; John&gt;      investigation disk.<br>
&gt;<br>
&gt; John&gt; I.E. they don&#39;t consider ro mode sufficient to not change the state of<br>
&gt; John&gt; the disk.<br>
&gt;<br>
&gt; I think you&#39;re missing the crucial issue here, it&#39;s an NFS mounted<br>
&gt; filesystem.  Unless the server exports ReadOnly, just because the<br>
&gt; client mounts it read-only doesn&#39;t mean the server can&#39;t update the<br>
&gt; atime if it likes.<br>
<br>
Not sure if my earlier message got eaten by spam filters.  This<br>
behavior is specified by POSIX and has been the source of extended<br>
debate in the Linux kernel community many of whose members find it as<br>
inexplicable as we do.  See, e.g.:<br>
<br>
<a href="http://lwn.net/Articles/244829/" target="_blank">http://lwn.net/Articles/<u></u>244829/</a><br>
<a href="http://thread.gmane.org/gmane.linux.kernel/565148" target="_blank">http://thread.gmane.org/gmane.<u></u>linux.kernel/565148</a><br>
<a href="http://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime" target="_blank">http://en.wikipedia.org/wiki/<u></u>Stat_%28system_call%29#<u></u>Criticism_of_atime</a><br>
<br>
I may also be missing the point you&#39;re trying to make.  :)<br>
<br>
Dave<br>
<br>
&gt; The true test would be to export RO from an NFS server, either the<br>
&gt; host NetApp in this case, or just any other NFS server and see what<br>
&gt; happens.  I suspect the atime updates depend more on the server side<br>
&gt; than on the client side.<br>
&gt;<br>
&gt; Now someone did make a change to mount with the noatime option, and<br>
&gt; that seemed to fix the issue, correct?  And it was still mounted RO,<br>
&gt; correct?<br>
&gt;<br>
&gt; Now how about if you export it purely RO from the server?  Does the<br>
&gt; noatime make a difference?   Heh, I&#39;ve got a Netapp and other systems<br>
&gt; at work I can play with, maybe I&#39;ll do a quick test volume and let<br>
&gt; people know... :-)<br>
&gt;<br>
&gt; ______________________________<u></u>_________________<br>
&gt; bblisa mailing list<br>
&gt; <a href="mailto:bblisa@bblisa.org" target="_blank">bblisa@bblisa.org</a><br>
&gt; <a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/<u></u>listinfo/bblisa</a><br>
<br>
______________________________<u></u>_________________<br>
bblisa mailing list<br>
<a href="mailto:bblisa@bblisa.org" target="_blank">bblisa@bblisa.org</a><br>
<a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/<u></u>listinfo/bblisa</a><br>
</blockquote>