4、文件系统挂载：SquashFS与OverlayFS的选择与优化
机顶盒启动过程中，文件系统挂载是个容易被忽视的环节。很多人觉得不就是挂个分区嘛，能有多大影响？我告诉你，这里面的门道可不少。选错了方案，启动时间可能多出两三秒。在嵌入式领域，这两三秒可能就是用户体验的天壤之别。
4.1 为什么文件系统会影响启动速度？
说白了，机顶盒启动时要做的事情就两件：加载内核，然后挂载根文件系统。文件系统挂载的快慢，直接决定了用户看到开机画面的时间。
我遇到过不少项目，硬件性能明明够用，但启动就是慢。查到最后，问题都出在文件系统上。你想想看，如果每次启动都要去校验、解压、加载一大堆文件，那速度能快吗？
机顶盒常用的文件系统方案主要有两种：
- SquashFS：只读压缩文件系统
- OverlayFS：联合文件系统，支持读写分层
这两种方案各有千秋，选哪个得看你的具体场景。
4.2 SquashFS：只读方案的王者
SquashFS是我个人比较偏爱的方案。它把整个文件系统压缩成一个镜像，启动时直接挂载，不需要解压到内存。这样做的好处很明显：
- 体积小：压缩率通常在2:1到3:1之间
- 挂载快：直接读取，无需解压过程
- 安全性高：只读，不怕意外断电损坏
我在一个项目中做过对比测试：同样的系统，用SquashFS比用ext4快了将近1.5秒。为什么？因为ext4在挂载时要执行fsck检查，而SquashFS完全不需要。
关键优化点：
SquashFS的挂载速度跟块大小（block size）密切相关。块越大，压缩率越高，但随机读取性能会下降。我个人习惯用128KB的块大小，这是性能和压缩率的平衡点。
来看一个典型的挂载命令：
# 挂载SquashFS根文件系统
mount -t squashfs -o ro,block_size=131072 /dev/mmcblk0p2 /rootfs4.3 OverlayFS：灵活性的代价
OverlayFS解决了一个实际问题：系统更新。SquashFS是只读的，要更新就得重新制作镜像。OverlayFS把文件系统分成上下两层：下层是只读的base层，上层是可写的overlay层。
但这里有个坑——我踩过。OverlayFS在挂载时，需要合并上下层的目录结构。如果文件数量多，这个合并过程会非常慢。
避坑指南：
我曾经在一个项目里，根文件系统有5000多个文件。用OverlayFS挂载，光合并目录就花了2.3秒。后来我把不常用的文件打包成SquashFS镜像，只对需要读写的目录用OverlayFS，启动时间直接砍掉了一半。
OverlayFS的挂载示例：
# 挂载OverlayFS
mount -t overlay overlay -o lowerdir=/base,upperdir=/overlay,workdir=/work /rootfs4.4 混合方案：取长补短
在实际项目中，我很少只用一种方案。更常见的做法是混合使用：
| 分区 | 文件系统 | 说明 |
|---|---|---|
| / | SquashFS | 系统核心文件，只读 |
| /data | ext4 | 用户数据，可读写 |
| /overlay | OverlayFS | 系统配置覆盖层 |
这样做的好处是：核心系统用SquashFS保证启动速度，用户数据用ext4保证灵活性，配置覆盖用OverlayFS实现OTA更新。
4.5 优化技巧总结
嗯，这里我总结几个实战中验证过的优化点：
- 减少文件数量：文件越多，挂载越慢。把零散的小文件合并成一个大文件，或者用busybox替代多个独立工具
- 调整块大小：SquashFS的块大小建议128KB-256KB，太大浪费空间，太小影响性能
- 预加载关键文件：把启动时需要用到的库和配置文件放在镜像的前面，减少寻道时间
- 关闭不必要的挂载检查：对于只读分区，可以跳过fsck
个人经验：
我习惯在制作SquashFS镜像时，用-mkfs-time参数指定文件排序规则。把启动脚本和核心库排在前面，这样挂载后第一次访问这些文件时，磁头不需要来回移动。别看这个细节小，在机械硬盘或eMMC上能省下几百毫秒。
最后说一句：文件系统的选择没有银弹。你得根据机顶盒的硬件配置、存储介质、更新策略来综合判断。但有一条原则不会变——启动路径上的文件越少、越集中，启动就越快。