为什么目前没有 Android 系统用 Btrfs（及可行性讨论）

[liyafe1997]

看华为 Mate50 发布会得到的启发，上面宣传的那个什么存储压缩技术以及从 B 站网友测的结果看，这其实不就是 CoW 和透明压缩嘛。

虽然华为用什么底层技术目前不得而知，但是似乎这些（ CoW 重复文件，压缩读多写少的文件）都可以用 Btrfs 文件系统实现。

现在似乎没有见过哪个 Android 厂家也好网友的 ROM 也好用上了 Btrfs 文件系统及用上这些特性，似乎用个 F2FS 都不得了了。。。杂粮手机到现在似乎都还是全盘 ext4 （ system/data/cache ）

于是有点想开个坑，魔改下 Android 给 data 配上 Btrfs 会如何，然后看看利用好这些特性能省多少空间，从目前我的脑补来看似乎技术上没有什么障碍（但可能会得到一个性能不太佳的 result ）。

还有个脑洞，就是现在很多 App 都加载大量第三方 SDK ，有大量的 native so 库，而且很多是相同的，是不是可以弄一套机制（也许用 Btrfs 的 CoW 就能直接实现），使得同版本的库可以共享一个 so 文件，节约空间。

[kkocdko]

也有同样的想法。补充一些：

1. “同版本的库可以共享一个 so” 有很多 deduplication 的工具，在 wiki 里有 https://btrfs.wiki.kernel.org/index.php/Deduplication 。
2. 我觉得目前 Android 使用的 AB 分区机制很糟糕，会浪费大量空间。同样地，如果使用 btrfs 快照来兜底更新，会自然很多（我在桌面 linux 下就是这样做的，fedora 36 ）。
3. 进一步地，可以减少存储芯片上的实际的分区数量，用单个分区，创建多个 btrfs subvolume ，将多个目录（ system / data / cache / 甚至 boot ）挂载到 subvol 上，避免固定大小分区浪费空间。
4. 可以使用 LZ4 透明压缩，比 ZSTD 快一些，毕竟移动端对续航要求比较高。

[ltkun]

我记得华为有个文件系统已经进入 linux 内核了 手机肯定对读写的要求和电脑不一样 不能完全照搬 空间问题根本不是问题 现在手机存储已经越来越大了 谁还会用 64G 以下的设备 主要安卓端设备实在太多 如果像 iPhone 就那么几款的话 随便定制折腾都可以

[jjpprrrr]

今年 LPC 2022 的 Android MC 上面，在讨论完 erofs 之后，问答环节有人问到了使用 btrfs 的问题。

?t=9630

对于 data 分区使用 btrfs ，Google 应该也是有类似的想法，我理解目前问题主要有两个：
1. fs-crypt: android 设备出厂，data 分区必须加密，而且目前要求必须是 FBE (File-Based Encryption)。btrfs 的 fs-crypt 支持应该还有些问题。
2. fs-verity: 主要是用来验证文件的 integrity 的，某些 app 文件用了证书签名之后，证书存到 /product/etc/security/fsverity ，在启动的时候加载，只有证书验证成功，app 文件才能正常读取。btrfs 同样也需要支持这个才行。

[s82kd92l]

@kkocdko 现在 android 用的是虚拟 a/b, 底层是 device mapper lvm 那一套，貌似已经解决 a/b 带来的空间浪费了

[s82kd92l]

我最近也在思考 android 存储方面魔改的问题。我希望做到的是利用 nas 或者 san 来扩充下手机容量，且可以供部分 app 使用，比如利用 iscsi+bcache 之类的挂载远程盘，然后把这个作为 data 分区给 island 里面的用户，以及非默认用户使用。或者让用户指定特定 app 使用，这样网络稳定性影响有限。

本质上是 per user remote storage 或者 per app remote storage, 有点像 @rikkaw 的 storage redirect, 但这个是连 app 的内部 dir 也要重新挂载。

[Zy143L]

杂粮手机的 data 是 f2fs 格式

[edis0n0]

有性能损耗吧，不然为什么不用更成熟，同样支持这些功能的 ZFS

[liyafe1997]

@Zy143L 我手上的杂粮手机还是全盘 ext4

[liyafe1997]

@jjpprrrr 好东西，感谢安利！

[liyafe1997]

@kkocdko “同版本的库可以共享一个 so” 这个我想的是在安装 apk 时就对里面的.so 做 hash ，然后和系统中已有的 hash 比较，之后不管是用 CoW 机制也好，甚至在当前 ext4 就能做到的直接做一个软 /硬链接到已有同 hash 的.so 。

[flynaj]

ext4 稳定性是有目共睹的。Btrfs 文件数量上去后性能就变差了。

[deorth]

更大的优势是用 subvol 代替一堆分区，连 /sdcard 也可以用 subvol 代替 fuse 改善性能。这事主要是谷歌不开，没有厂商会去动的。
至于谷歌不开的原因么，我有理由相信 btrfs 不稳定的论调是一个主要原因。目前也没有服务器发行版默认使用 btrfs ，说明 btrfs 确实还没有得到广泛信任。

[liyafe1997]

@deorth 对的，这个 sdcardfs 不知倒腾了多少次，太影响性能了

[agagega]

iOS 的 APFS 也是 CoW 的，但没有 dedup ，可能对于小内存移动设备，dedup 太不可靠也费资源吧

[Zy143L]

@liyafe1997 我 11u data 分区是 f2fs miui 开发版

[OnlineParty]

现在 Android12 的 System 分区都是 erofs 了

[ztc1997]

@liyafe1997 我的粗粮手机 /system 是 erofs ，data 是 f2fs 。

[butterls]

文件去重这个事 19 、20 年左右 F2FS 的 某个大佬想做来的，后来据说被非技术原因否掉了

单说收益，对于一般不手动清理的用户，只要把微信和图库做去重，省出来几个 G 松松的

云侧做这个是有大大的利益的，端侧厂商做这种事情没啥收益，空间省了设备磁盘空间咋卖，退一万步讲单单有心人炒作个操作系统扫描用户文件涉及隐私安全都要解释半天（虽然现在卖数据的应用都把用户文件要扫烂了）

[krixaar]

Jolla Phone 1 就是 btrfs ，然后 *此处是脏话* 小毛病就不断，确实 CoW/快照什么的好使的一匹，但是可用容量开始变少的时候（毕竟 Jolla1 就 16G……），会出现有空间写不进去东西的情况，就得手动做 balance ，然后这个过程在 Jolla1 那个孱弱的硬件上跑起来还贼慢，balance 中途因为任何原因断了都会直接 corrupt 整个文件系统，怕砖就不能随便 balance ，不 balance 就影响读写性能，最后 Jolla 就直接放弃治疗，之后的设备都是 ext4 。

谁爱用谁用去，安卓上 btrfs 我第一个反对。

[WebKit]

@liyafe1997 ext4 好啊，我都是直接把 f2fs 格式化成 ext4 用的。玩机或者刷机 ext4 最方便，其他的格式不能在 recovery 中解密分区

[yanqiyu]

@jjpprrrr fs-verity 对于 btrfs 应该是已经实现了，这么一看整个拼图缺的只是 fs-crypt ？近期有人在提交 patch ，但是估计也要很长时间才能合并并稳定到可用的程度


@krixaar btrfs 的设计应该没那么容易就 corrupted ，或者说恰好选了一个有 bug 的内核版本？

[yanqiyu]

@kkocdko
> 2. 我觉得目前 Android 使用的 AB 分区机制很糟糕，会浪费大量空间。同样地，如果使用 btrfs 快照来兜底更新，会自然很多（我在桌面 linux 下就是这样做的，fedora 36 ）。

android 现在更新机制应该是块级的 diff ？要是借助子卷的话可能只能分发 btrfs send stream
这样子就和 android 喜欢的 dm-verity 机制又不兼容了，当然，一起迁移到 fs-verity/想办法基于 btrfs HMAC 实现验证也是办法

[krixaar]

@yanqiyu #21 前情提要：Jolla Phone 是 2013 年的产品。
当年 JP1 上面那个 btrfs 什么都好，就是要 balance ，不然 metadata 写满了，你看着有 1 个 G 的空闲空间，一个字节都写不进去。那个 balance 的过程不能意外断（可以手动停），自己得盯着手机电量，确保流程正常结束，万一出了差错大概率直接砖掉（或者 boot loop ，然后去 btrfs recovery ）。
那个版本连官方都建议 16G 的手机内置存储使用不要超过 7G ，多了自己要去 btrfs-balancer allocation 去查 metadata 还剩多少，快满了赶紧 balance 。特别闹心的一段使用体验，每次系统更新都得心惊胆战一下。
这事儿就像我当年预购了 No Man's Sky ，你说现在这么多年了 NMS 已经是个好游戏了，但当年给我带来的失望就让我完全不想再去玩一下。

[jjpprrrr]

@yanqiyu #22 从 android 11 开始，绝大多数新设备出厂就是 virtual a/b 了，android 13 开始应该是强制要求新设备必须 virtual a/b 。virtual a/b 已经不怎么浪费空间了，我觉得最大的缺点是 OTA 比较慢，耗费 CPU ，好在可以后台慢慢做。

[weixiansen574]

Android11 的 fuse 文件系统够蛋疼了，红米 k40Pro+，文件系统性能为 59 IO/s ，10 年前的小米 2s 都有 200 多 IO/s 的性能，倒车油门踩到底呢这是！解压个安卓内核源码压缩包要死人了，虽然不大但是都是零碎的小文件，费几个小时才解压完成。老前辈小米 8 正常多了，1000 多的 IO/s ，解压安卓内核也几分钟的时间。

[liyafe1997]

@krixaar 感觉这个完全可以软件优化好，比如可以充电的时候自动 balance ，或者采取一些其它的 workaround

[EnochZack]

btrfs 虽然看起来很好，但是并不是一个稳定的文件系统，ext4 虽然比较古老，但是非常稳，手机的用户太多了，只要出任何一点问题都会有不可估量的损失

[sky96111]

@deorth OpenSUSE 企业版 SLES 已经系统盘默认 btrfs ，并利用 CoW 特性实现系统快照了

[Songine]

确实，特别是几个媒体文件目录，占的多，用的少，完全可以用 btrfs 作透明压缩