Re: [PATCH] btrfs: Introduce new mount option to disable tree log replay

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

On 2015-12-07 18:06, Eric Sandeen wrote:
> On 12/7/15 2:54 PM, Christoph Anton Mitterer wrote:
>
> ...
>
>> 2) a section that describes "ro" in btrfs-mount(5) which describes that
>> normal "ro" alone may cause changes on the device and which then refers
>> to hard-ro and/or the list of options (currently nologreplay) which are
>> required right now to make it truly ro.
>>
>>
>> I think this is important as an end-user probably expects "ro" to be
>> truly ro,
>
> Yeah, I don't know that this is true.  It hasn't been true for over a
> decade (2?), with the most widely-used filesystem in linux history, i.e.
> ext3.  So if btrfs wants to go on this re-education crusade, more power
> to you, but I don't know that it's really a fight worth fighting.  ;)
>
Actually, AFAICT, it's been at least 4.5 decades.  Last I checked, this 
dates back to the original UNIX filesystems, which still updated atimes 
even when mounted RO.

Despite this, it really isn't a widely known or well documented behavior 
outside of developers, forensic specialists, and people who have had to 
deal with the implications it has on data recovery.  There really isn't 
any way that the user would know about it without being explicitly told, 
and it's something that can have a serious impact on being able to 
recover a broken filesystem.  TBH, I really feel that _every_ 
filesystem's documentation should have something about how to make it 
mount truly read-only, even if it's just a reference to how to mark the 
block device read-only.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]