>>>>> "John" == John P Rouillard <[email protected]> writes:
John> In message John> <CAJFsZ=obbwr7n_1bcjbo2e-dhjrqwp8mxgeu4tadmbkwz1b...@mail.gmail.com> , John> Bill Bogstad writes: >> On Thu, Dec 5, 2013 at 10:03 AM, Edward Ned Harvey (bblisa4) >> <[email protected]> wrote: >>>> From: [email protected] [mailto:[email protected]] On >>>> Behalf Of Alex Aminoff >>>> >>>> Nevertheless, I tested it and unless I messed up my test, an NFS mount >>>> with -o ro, you read a file on the mounted FS, and the access time is >>>> updated. >>> >>> Oh - that could explain it right there - >>> >>> I think the client isn't the one doing the update. I think your >>> server is updating the last access time on the file, because the >>> server served the file to the client. The server doesn't >>> necessarily know you mounted read-only >> >> That makes a lot of sense. Alex doesn't say what version of the NFS >> protocol he is using, but a quick check of the RFC for the MOUNT >> protocol for NFSv3 (see page 105 for mount protocol >> http://www.ietf.org/rfc/rfc1813.txt) doesn't seem to give a way for a >> client to indicate that it wants to mount a filesystem as readonly. >> Maybe someone who is more familiar with the NFS protocol can confirm >> this. John> That is my understanding as well. John> Also mounting a filesystem ro IIRC used to change some metadata John> in the filesystem. Maybe last mount time, number of times John> mounted ... depending on the FS type. John> I know from forensics work there can be a bunch of things that John> will change the filesystem/disk state. Hence most forensics John> people: John> 1) use a hardware rig that will NOT issue write commands to the John> source disk to copy the source disk to a disk they will use John> for investigation. John> 2) use tools that are designed to not mess up the filesystem in the John> investigation disk. John> I.E. they don't consider ro mode sufficient to not change the state of John> the disk. I think you're missing the crucial issue here, it's an NFS mounted filesystem. Unless the server exports ReadOnly, just because the client mounts it read-only doesn't mean the server can't update the atime if it likes. The true test would be to export RO from an NFS server, either the host NetApp in this case, or just any other NFS server and see what happens. I suspect the atime updates depend more on the server side than on the client side. Now someone did make a change to mount with the noatime option, and that seemed to fix the issue, correct? And it was still mounted RO, correct? Now how about if you export it purely RO from the server? Does the noatime make a difference? Heh, I've got a Netapp and other systems at work I can play with, maybe I'll do a quick test volume and let people know... :-) _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
