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

2022-10-06 07:58:01 +08:00
 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 文件,节约空间。

12799 次点击
所在节点    Android
29 条回复
kkocdko
2022-10-06 10:06:19 +08:00
也有同样的想法。补充一些:

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
2022-10-06 10:15:30 +08:00
我记得华为有个文件系统已经进入 linux 内核了 手机肯定对读写的要求和电脑不一样 不能完全照搬 空间问题根本不是问题 现在手机存储已经越来越大了 谁还会用 64G 以下的设备 主要安卓端设备实在太多 如果像 iPhone 就那么几款的话 随便定制折腾都可以
jjpprrrr
2022-10-06 10:25:21 +08:00
今年 LPC 2022 的 Android MC 上面,在讨论完 erofs 之后,问答环节有人问到了使用 btrfs 的问题。<amp-youtube data-videoid="PW7XA237dgI" layout="responsive" width="480" height="270"></amp-youtube>?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
2022-10-06 11:09:36 +08:00
@kkocdko 现在 android 用的是虚拟 a/b, 底层是 device mapper lvm 那一套,貌似已经解决 a/b 带来的空间浪费了
s82kd92l
2022-10-06 11:20:22 +08:00
我最近也在思考 android 存储方面魔改的问题。我希望做到的是利用 nas 或者 san 来扩充下手机容量,且可以供部分 app 使用,比如利用 iscsi+bcache 之类的挂载远程盘,然后把这个作为 data 分区给 island 里面的用户,以及非默认用户使用。或者让用户指定特定 app 使用,这样网络稳定性影响有限。

本质上是 per user remote storage 或者 per app remote storage, 有点像 @rikkaw 的 storage redirect, 但这个是连 app 的内部 dir 也要重新挂载。
Zy143L
2022-10-06 13:35:30 +08:00
杂粮手机的 data 是 f2fs 格式
edis0n0
2022-10-06 13:45:11 +08:00
有性能损耗吧,不然为什么不用更成熟,同样支持这些功能的 ZFS
liyafe1997
2022-10-06 14:51:31 +08:00
@Zy143L 我手上的杂粮手机还是全盘 ext4
liyafe1997
2022-10-06 15:46:59 +08:00
@jjpprrrr 好东西,感谢安利!
liyafe1997
2022-10-06 18:05:22 +08:00
@kkocdko “同版本的库可以共享一个 so” 这个我想的是在安装 apk 时就对里面的.so 做 hash ,然后和系统中已有的 hash 比较,之后不管是用 CoW 机制也好,甚至在当前 ext4 就能做到的直接做一个软 /硬链接到已有同 hash 的.so
flynaj
2022-10-06 21:44:06 +08:00
ext4 稳定性是有目共睹的。Btrfs 文件数量上去后性能就变差了。
deorth
2022-10-06 23:12:44 +08:00
更大的优势是用 subvol 代替一堆分区,连 /sdcard 也可以用 subvol 代替 fuse 改善性能。这事主要是谷歌不开,没有厂商会去动的。
至于谷歌不开的原因么,我有理由相信 btrfs 不稳定的论调是一个主要原因。目前也没有服务器发行版默认使用 btrfs ,说明 btrfs 确实还没有得到广泛信任。
liyafe1997
2022-10-07 01:33:16 +08:00
@deorth 对的,这个 sdcardfs 不知倒腾了多少次,太影响性能了
agagega
2022-10-07 02:36:28 +08:00
iOS 的 APFS 也是 CoW 的,但没有 dedup ,可能对于小内存移动设备,dedup 太不可靠也费资源吧
Zy143L
2022-10-07 02:51:12 +08:00
@liyafe1997 我 11u data 分区是 f2fs miui 开发版
OnlineParty
2022-10-07 18:15:05 +08:00
现在 Android12 的 System 分区都是 erofs 了
ztc1997
2022-10-07 19:22:06 +08:00
@liyafe1997 我的粗粮手机 /system 是 erofs ,data 是 f2fs 。
butterls
2022-10-08 07:02:32 +08:00
文件去重这个事 19 、20 年左右 F2FS 的 某个大佬想做来的,后来据说被非技术原因否掉了

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

云侧做这个是有大大的利益的,端侧厂商做这种事情没啥收益,空间省了设备磁盘空间咋卖,退一万步讲单单有心人炒作个操作系统扫描用户文件涉及隐私安全都要解释半天(虽然现在卖数据的应用都把用户文件要扫烂了)
krixaar
2022-10-08 09:32:26 +08:00
Jolla Phone 1 就是 btrfs ,然后 *此处是脏话* 小毛病就不断,确实 CoW/快照什么的好使的一匹,但是可用容量开始变少的时候(毕竟 Jolla1 就 16G……),会出现有空间写不进去东西的情况,就得手动做 balance ,然后这个过程在 Jolla1 那个孱弱的硬件上跑起来还贼慢,balance 中途因为任何原因断了都会直接 corrupt 整个文件系统,怕砖就不能随便 balance ,不 balance 就影响读写性能,最后 Jolla 就直接放弃治疗,之后的设备都是 ext4 。

谁爱用谁用去,安卓上 btrfs 我第一个反对。
WebKit
2022-10-08 11:50:50 +08:00
@liyafe1997 ext4 好啊,我都是直接把 f2fs 格式化成 ext4 用的。玩机或者刷机 ext4 最方便,其他的格式不能在 recovery 中解密分区

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/884834

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX