On 2015-12-08 14:20, Christoph Anton Mitterer wrote:
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).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 =)
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).
smime.p7s
Description: S/MIME Cryptographic Signature
