[BBLISA] Does read only really mean it?

[Bill Bogstad]

On Fri, Dec 6, 2013 at 1:14 PM, Dave Allan <dave at dpallan.com> wrote:

> 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.  :)

I don't see the issue being the performance aspects of atime (which as
far as I can tell is what
is being discussed in those links).   The issue is how should atime be
treated if a filesystem is mounted
read-only.   Linux has a "noatime" mount option which one would hope
would result in atimes never changing
on local native filesystems mounted with otherwise default options.
One might also desire that using the "ro" mount option would result in
the same thing.  Whether those same desired results will occur when
the situation involves NFS and the server isn't Linux is clearly going
to be more problematic.

As for your POSIX comment, it may be just my poor search skills, but I
can't find either the mount command or mount()
call as being part of POSIX in the resources that I checked.  Maybe we
should just assume that using "ro", "noatime", or even NFS takes us
outside the scope of POSIX and anything could happen.   Given that
some commercial unices claim to be fully POSIX compliance, I wonder if
there any notes in their test documents on what filesystems/mount
options you have to use to have a fully compliant system.

Bill Bogstad