[BBLISA] Does read only really mean it?

[Matt Simmons]

I would agree, except that Alex indicated that noatime causes the correct
behavior.


On Wed, Dec 4, 2013 at 11:24 PM, Brian O'Neill <oneill at oinc.net> wrote:

> I'm thinking the atime is being updated by the server because the server
> accessed the file in order to serve it...
>
> 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 be
>>  havior
>> - 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, becau
>>>  se
>>> 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
>>
>>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>



-- 
"Today, vegetables... Tomorrow, the world!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.bblisa.org/pipermail/bblisa/attachments/20131205/52c180c0/attachment-0001.htm