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

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

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

On 2015-12-08 14:20, Christoph Anton Mitterer wrote:
> On Tue, 2015-12-08 at 07:15 -0500, Austin S Hemmelgarn wrote:
>> 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.
> Exactly what I've meant.
>
> And the developers here, should definitely consider that every normal
> end-user, may easily assume the role of e.g. a forensics specialist
> (especially with btrfs ;-) ), when recovery in case of corruptions is
> tried.
>
>
> I don't think that "it has always been improperly documented" (i.e. the
> "ro" option) is a good excuse to continue doing it that way =)
Agreed, 'but it's always been that way' is never a valid argument, and 
the fact that people who have been working on UNIX for decades know it 
doesn't mean that it's something that people will just inherently know. 
  The only reason it was that way to begin with is because it was 
assumed that everyone dealing with computers had a huge amount of domain 
specific knowledge of them (this was a valid assumption back in 1970, it 
hasn't been a valid assumption since at least 1990).

Stuff that seems obvious to people who have been working on it for years 
isn't necessarily obvious to people who have limited experience with it 
(I recently had to explain to a friend who had almost no networking 
background how IP addresses are just an abstraction for MAC addresses, 
and how it's not possible to block WiFi access based on an IP address; 
it took me three tries and eventually making the analogy of street 
addresses being an abstraction for geographical coordinates before he 
finally got it).

TBH, the only reason I knew about this rather annoying detail of 
filesystem implementation before using BTRFS is because of dealing with 
shared storage on VM's (that was an interesting week of debugging and 
restoring backups before I finally figured out what was going on).



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