[BBLISA] Does read only really mean it?

[Dave Allan]

On Fri, Dec 06, 2013 at 02:00:23PM -0500, Bill Bogstad wrote:
> 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.

Wow, I seem to have gotten that totally backward, sorry everybody.
Indeed the performance discussion was entirely about rw mounted
filesystems.  FWIW, and at the risk of making myself look like even
more of a spec lawyer than I actually am, now that I've gone and
looked at the spec, it says specifically:

"4.8 File Times Update ... Marks for update, and updates themselves,
shall not be done for files on read-only file systems"[1]

So, I'm shocked, SHOCKED to discover that the implementation discussed
here is not compliant.

Excuse me while I go find a rock to hide under.

Dave


[1]

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_08