[BBLISA] Does read only really mean it?
Theo Van Dinter
felicity at kluge.net
Sat Dec 14 12:47:28 EST 2013
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
http://www.freebsd.org/cgi/man.cgi?query=mount_nfs&sektion=8 and
http://linux.die.net/man/5/nfs, for example, there doesn't seem to be a
"noatime" option for NFS mounts at all.
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.
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.
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:
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
[...]
When mounting an ext4 filesystem, the following option are accepted:
ro Mount filesystem read only. Note that ext4 will
replay the journal (and thus write to the
partition) even when mounted "read only". The
mount options "ro,noload" can be used to prevent
writes to the filesystem.
[...]
Also fwiw, the older version of TR-3183 from NetApp (
http://olug.org/presentations/March2005/nfs.pdf, Using the Linux NFS Client
with Network Appliance Filers) has a section that says:
[...]
It is a common trick for system administrators to use the “noatime” mount
option on local file systems to improve overall file system performance by
preventing a synchronous metadata update every time a file is accessed in
some way. Because NFS servers, not clients, control the values contained in
a file’s timestamps (access time, metadata change time, and data modify
time) by default, this trick is not effective for NFS mounts. However,
filers allow you to reduce the overhead caused by aggressive atime flushing
if you set a volume’s no_atime_update option. On a filer console, type
“help vol options” for details.
[...]
On Sat, Dec 7, 2013 at 2:24 PM, Dean Anderson <dean at av8.com> wrote:
>
> Hi folks,
>
> Its been a while. I've been lurking tho.
>
> There is no mystery: The nfs server itself doesn't have the filesystem
> mounted read-only. So the client should respect the RO on nfs mount.
> However, actually reading the file causes the nfs server itself to
> access the file, and since that system isn't mounting its own disk read
> only, it updates atime--as it should.
>
> Try mounting the exported filesystem readonly on the filesever and see
> what happens...
>
> --Dean
>
> On Dec 4, 2013, at 10:37 PM, Alex Aminoff <alex at basespace.net> wrote:
>
> On 12/4/2013 10:21 PM, Matt Simmons wrote:
> My knowledge is somewhat limited to the Linux world, but in my
> experience I've never seen a mount be set to 'ro' and have anything
> updated. I hate to use the term 'flabbergasted', but I'm pretty sure
> that if I saw an implementation that didn't respect the 'ro' flag, I'd
> be at the very least 'put out', and perhaps even vitriolic.
>
> Yeah, flabbergasted is a good description of how I felt.
>
> 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.
>
> For the test the server was a NetApp, the client was Linux.
>
> There is a mount flag -o noatime that does what I want. But I would
> argue that this is not right. The simplest behavior - nothing is ever
> written period - should be what you get by default, and then there could
> be a flag that enables exceptional behavior, that is updating the access
> time.
>
> I can squint and see why it would be the way it is. One perspective is
> that the naive assumption is that reading off a RO filesystem should be
> just like reading any other way; when you read, the OS conveniently
> remembers when you did. The inconsistency of "writing" to a read-only
> thing is less important than the inconsistency of not updating the
> access time when the file is read.
>
> But what if the underlying device is not capable of recording access
> times, like a CD-ROM? Can you look at the mount options and see that a
> CDROM is read-only? But then you can't know whether access times will be
> updated unless you use some other method to find out what the underlying
> device is. So that's an abstraction violation. Bother, I don't have a
> unix box easily to hand where I can check what the mount options on a
> CDROM look like.
>
> I'm not sure if this is just grousing, or flame bait, or a gotcha that
> every sysadmin should know because there is no way to anticipate it.
>
> - Alex
>
> --Matt
>
>
>
> On Tue, Dec 3, 2013 at 2:21 PM, Alex Aminoff <alex at basespace.net
> <mailto:alex at basespace.net>> wrote:
>
>
> Hi folks. I encountered something odd.
>
> Suppose you mount a file system read only. You read a file from
> it. Does
> the access time of that file get updated?
>
> In one place I found documentation saying no. But other places seem to
> imply that it does.
>
> Does the answer change if it is an NFS mount?
>
> I have deliberately left details of what OS I'm using out, because it
> seems to me that the answer should be consistent, and if it is not, it
> should be documented publicly.
>
> - Alex Aminoff
> BaseSpace.net, NBER
>
>
>
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org <mailto:bblisa at bblisa.org>
> http://www.bblisa.org/mailman/listinfo/bblisa
>
>
>
>
> --
> "Today, vegetables... Tomorrow, the world!"
>
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bblisa.org/pipermail/bblisa/attachments/20131214/49e8c589/attachment.html>
More information about the bblisa
mailing list