阿茶
Coelacanthus 😶🌫️ 🏳️⚧️强烈建议各位 #Linux 系统管理员将内核升级到 6.8 以上并且设置 bdev_allow_write_mounted=0 内核参数，建议发行版维护者将 BLK_DEV_WRITE_MOUNTED 内核选项设置为 no。该内核参数会在 #块设备 上的 #文件系统 被挂载时阻止对该块设备的直接写入行为。可用于防止误操作同时在多个系统（比如多个虚拟机、宿主机和虚拟机）上挂载同一个块设备的文件系统，或者在挂载文件系统时 dd 写入对应的块设备。以上行为皆会因为不同步的状态导致数据损坏。
https://github.com/torvalds/linux/commit/ed5cc702d311c14b653323d76062b0294effa66e
在这里点名批评 #WinBtrfs 默认的自动以可读写方式挂载所有看到的 #btrfs 的行为。Cryolitia 同学近日将整个盘传给虚拟机以启动位于其中一个分区上的 #Windows，该 Windows 里安装了 WinBtrfs，于是在系统启动之时 WinBtrfs 自动挂载了盘上的 btrfs 分区，虚拟机内外在状态不互通不同步的情况下分别对文件系统进行了修改，导致文件系统的一致性被完全破坏，造成了严重的数据损坏，所幸 Cryolitia 有备份的习惯，数据得以从备份中恢复，没有酿成大祸。
WinBtrfs 在其写入支持并不完全（log tree 并未实现）也不可靠（经常出现导致文件系统故障的问题）的情况下自动以读写方式挂载，也给很多不知情的新用户带来了数据和文件系统损坏的风险。既然开发者有时间在 README 里添加免责声明，那么为什么不将默认的挂载行为设置为只读挂载呢？而不是在明知写入支持存在问题的情况下将这个特性为所有用户默认启用。
https://github.com/Cryolitia
https://github.com/maharmstone/btrfs
糖喵💕🍭(◍•ᴗ•◍)✧*@coelacanthus 或许是因为对一般用户来说，如果默认挂载出来的是一个只读的文件系统，会更加困惑甚至怀疑程序有问题吧（一般觉得没有特殊指定只读的话文件系统就默认是读写的？） 
发现问题了提一个解决 PR 应该不难？
发现问题了提一个解决 PR 应该不难？
@Candinya 那也要比让用户暴露在极大的文件系统损坏的风险下要好吧，尤其是你把这个行为和自动挂载结合起来看，这个问题危害就更大了。
此外这个修改是被上游明确拒绝的，上游和你指出的思路一样，觉得对于一个文件系统来说数据安全（Data Safety）不如最小惊讶原则重要（the principle of least astonishment）。虽然我觉得用户用过 winbtrfs 之后发现自己文件系统/数据损坏了才会是最惊讶的。
https://github.com/maharmstone/btrfs/issues/52
WinBtrfs 作者还有一些类似的观点，比如他觉得 Btrfs 保证写入的一致性与数据安全的一个重要环节 log tree 是一个**小众**的需求。（log tree 用于记录 Btrfs 两次 transaction commit 之间的写入，如果没有这个特性当发生意外断电等情况是，文件系统最多会丢失 30s（默认的 commit 间隔）的系统已经向应用**保证写入**了数据）
https://github.com/maharmstone/btrfs/issues/637#issuecomment-2017078001
此外这个修改是被上游明确拒绝的，上游和你指出的思路一样，觉得对于一个文件系统来说数据安全（Data Safety）不如最小惊讶原则重要（the principle of least astonishment）。虽然我觉得用户用过 winbtrfs 之后发现自己文件系统/数据损坏了才会是最惊讶的。
https://github.com/maharmstone/btrfs/issues/52
WinBtrfs 作者还有一些类似的观点，比如他觉得 Btrfs 保证写入的一致性与数据安全的一个重要环节 log tree 是一个**小众**的需求。（log tree 用于记录 Btrfs 两次 transaction commit 之间的写入，如果没有这个特性当发生意外断电等情况是，文件系统最多会丢失 30s（默认的 commit 间隔）的系统已经向应用**保证写入**了数据）
https://github.com/maharmstone/btrfs/issues/637#issuecomment-2017078001
shironeko@coelacanthus @Candinya 如果没有数据丢失windows用户会不知所措
@coelacanthus 确实，感觉这个项目更注重的是 it works ，而不是 production ready
或许可以 fork 一份然后对安全性相关的需求进行针对性优化
或许可以 fork 一份然后对安全性相关的需求进行针对性优化
@Candinya 如果只是改那个默认读写挂载的话感觉有点小题大做（而且只改这一点的话也很难让用户迁移到这个分支），但是实现 log tree 又需要对 Windows 内存管理和存储子系统有非常深的理解……
YetAnotherエスポワール@coelacanthus 原来我的 / 就是这么坏的么😥