It wasn't so much eaten by spam filters as "contained the word POSIX so everyone's eyes glazed over and we went into comas" :)
On Fri Dec 06 2013 at 1:14:48 PM, Dave Allan <[email protected]> wrote: > On Fri, Dec 06, 2013 at 09:36:01AM -0500, John Stoffel wrote: > > >>>>> "John" == John P Rouillard <[email protected]> writes: > > > > John> In message > > John> <CAJFsZ=oBBwr7n_1BcJBO2e-DHJrQWp8mxGEU4tADmBkWz1Bdfw@ > 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. > > Not sure if my earlier message got eaten by spam filters. This > behavior is specified by POSIX and has been the source of extended > debate in the Linux kernel community many of whose members find it as > inexplicable as we do. See, e.g.: > > http://lwn.net/Articles/244829/ > http://thread.gmane.org/gmane.linux.kernel/565148 > http://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime > > I may also be missing the point you're trying to make. :) > > Dave > > > 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 > > _______________________________________________ > bblisa mailing list > [email protected] > http://www.bblisa.org/mailman/listinfo/bblisa >
_______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
