先别急着翻 logcat。Android 上遇到 Ext4 文件系统问题头一件要做的往往是退后一步想清楚问题到底出在文件系统本尊身上还是出在更上层的文件管理框架里。我见过不少人把 /storage/emulated/0/Android/data 目录下的文件访问失败当成 Ext4 权限故障来查最后花了两天时间才发现和 Ext4 一毛钱关系都没有。我在 Android 系统开发和嵌入式 Linux 移植上摸爬滚打这些年Ext4 的坑踩得不算少从 /data 分区挂载失败、fsck 修复不当导致数据丢失到 chmod 提示 Operation not permitted再到线上服务器 CPU 被 I/O 拖到 100%每一类问题的排查路径其实都有规律。这篇文章就是把这些规律一次性讲透把原理、操作、案例和避坑心得整理成一条完整的排查链路给做 Android Framework 开发、系统移植、应用兼容性调试的同学一份可以直接按图索骥的参考。1. 为什么 Android 上的 Ext4 问题值得单独排查1.1 先看一张分区地图Android 设备里Ext4 并不负责所有存储。一台典型的手机从上到下大概有这些分区boot、system、vendor、product、data、cache、misc 等。其中 system、vendor 和 data 在大部分机型上用的都是 Ext4部分新机型 data 分区会改用 F2FS。用户日常看到的“内部存储”也就是 /storage/emulated/0并不是直接挂载的 Ext4 分区而是通过 FUSE 或 sdcardfs 叠在 /data/media 之上的一层视图。这个视图把同一个 Ext4 分区的一部分内容以模拟外置 SD 卡的方式暴露给 App。如果没想清楚这一点很容易把上层文件管理的问题赖到 Ext4 头上或者反过来漏掉真正的 Ext4 故障。这个区分非常关键因为两条链路的排查方式几乎完全相反。Ext4 层出问题优先看内核日志、文件系统状态和 mount 参数FUSE/sdcardfs 层出问题优先看 SELinux 策略、包管理器状态和 App 的 uid/gid。系统工程师拿到一台“文件系统有问题”的设备第一步不是去翻代码而是先把 mount、ps -A、dmesg 这几条命令的输出抓到判断物理分区是否正常再谈上层。1.2 大多数“文件系统问题”其实是管理框架问题实际操作中我遇到最多的所谓“Android Ext4 故障”集中在三类场景。第一类是 App 在 /storage/emulated/0/Android/data/ 自己的包名目录下写文件失败或者写入后找不到报错往往是 Permission denied 或 File not found。第二类是解锁或 OTA 后 /data 分区无法挂载开机卡在“Android 正在启动”或直接进 recovery。第三类是莫名其妙的卡顿伴随 logcat 里的 I/O 错误系统 CPU 占用飙升。三类场景里真正由 Ext4 本身引起的可能只有第二类和一部分第三类。第一类绝大多数是 Android 的存储权限模型在起作用也就是分区存储Scoped Storage和 FUSE 实现带来的“文件被搬走、重命名、目录不可访问”等行为。排查时如果不先做这个分层一上来就去跑 e2fsck既浪费时间又有可能把还没损坏的文件系统搞坏。所以我在下文中会把两类问题都讲但会明确区分哪一层解决什么问题这是排查效率的关键。1.3 哪些团队迟早都会碰到这个问题这个问题覆盖的读者比想象中宽。做系统移植的工程师最怕的是 Ext4 的 feature 开关和内核版本不匹配导致挂载失败做 App 适配的需要理解 Android/data 路径的 FUSE 层权限变化做嵌入式 Linux 的会发现在 NFS 根文件系统上跑得好好的程序一到真机 Ext4 上就出现 fsync 耗时暴增或文件丢失。哪怕你是做后台服务器的线上根分区 Ext4 因为 inode 耗尽或脏页写回异常导致 CPU 100%排查思路也高度一致。所以这篇不是写给某一个特定岗位而是写给所有需要直面 Linux 存储栈的人。2. 排查前必须搞清的三个底层机制2.1 “空间不足”可能真的不是空间不足文件系统“满了”这个现象一般人第一反应是 df 看剩余空间。但 Ext4 上有几个更隐蔽的“满”会让你误判。第一个是 inode 耗尽df 显示还有几十 GB但文件的 inode 号已经分配完任何新建文件都报 No space left on device。第二个是保留块比例Ext4 默认给 root 保留 5% 的空间普通 App 在用户空间统计可用空间时看到的是全部大小实际写入时到了 95% 就写不进去了。第三个是单文件大小、目录项数量等元数据限制超过上限同样报错。排查这类问题不能只看 df。完整思路是 df -i 看 inodedf -h 看容量tune2fs -l /dev/block/xxx 看保留块比例和当前挂载次数。我在一个项目里遇到 App 频繁报“存储满”查了一圈发现是另一个守护进程疯狂创建日志文件把 inode 吃光了日志文件因为太小被 logrotate 跳过看起来空间还有一大半。用 df -i 定位后几分钟就解决了。记住任何磁盘满排查先同时确认容量和 inode再往下查。2.2 page cache、writeback 与 sync/fsync 的真相Ext4 是日志文件系统但不是“写入立刻落盘”。内核先把数据写进 page cache标记为脏页然后由 writeback 机制在后台按策略刷入磁盘。App 调用 fsync或系统触发 sync 时才强制把脏页刷下去。这个设计极大提升了 I/O 性能但也制造了一类经典故障断电或内核 panic 后应用程序认为已经写完的数据因为还没落盘而丢失或者目录项与数据块的日志状态不一致启动时 fsck 要扫描很久甚至报错。排查 I/O 问题时这个机制解释了为什么同一个操作在模拟器、NFS、F2FS 上的表现完全不同。例如在 NFS 根文件系统里因为网络 I/O 慢你看到的耗时主要在等待网络在 Ext4 上耗时可能来自日志提交JBD2和脏页回写。用 /proc/vmstat 里的 nr_dirty、dirty_writeback_centisecs 参数以及 mount 参数里的 datawriteback/ordered能快速判断当前策略。很多人看到卡顿就去调 I/O 调度器其实先确认 writeback 参数更有效。2.3 SELinux、挂载选项与“Permission denied”Ext4 本身有传统的权限位、属主和 ACL而 Android 在它之上还套了一层 SELinux。同一个文件unix 权限是 777SELinux policy 不允许照样返回 Permission denied。更麻烦的是 sdcardfs 或 FUSE 层还会根据 App 的包名、uid 以及目标目录归属动态决定是否允许访问。于是会出现这种诡异情况adb shell 以 root 身份 chmod 一个目录返回 Operation not permitted换个目录却可以。原因是目标目录所在的挂载点可能有 nosuid、noexec、nodev 或只读选项也可能是 SELinux 的 type 标签不匹配。这里要记住排查顺序先 ls -lZd 确认属主和 SELinux 标签再 mount 查挂载选项最后才去怀疑文件系统损坏。实际案例里卸载重装 App“解决”了问题多数情况是应用重新创建了带正确标签的目录而不是 Ext4 被修复了。看到这类操作成功就判定为 Ext4 故障是典型误判。3. 问题排查方法论先定位再动手3.1 信息收集“三件套”拿到故障机后我的固定动作是抓三样东西。第一个是 dmesg看内核有没有 EXT4-fs error、JBD2 warning、I/O error 这样的字眼。第二个是 logcat看应用层、vold、installd 这些进程抛出的异常尤其是 PackageManager 和 StorageManager 相关日志。第三个是当前挂载状态执行 mount 并筛选 ext4、f2fs、sdcardfs、fuse。这三样能覆盖从内核到用户态的主流故障信号也是后续定位根因的底座。抓日志的同时记录操作步骤的复现路径是重启后必现还是运行某个 App 后偶发还是 OTA 之后才开始。这一步很多人会跳过去直接搜报错关键词但复现路径直接决定了排查方向。例如重启后必现的挂载失败优先怀疑分区状态、fsck 和内核驱动的兼容性偶发 I/O 错误则更可能是硬件链路的稳定性问题。3.2 用排除法做分层定位我的习惯是把问题分成三层文件系统层、内核通用层、应用层。文件系统层看的是 Ext4 元数据、日志、挂载参数内核通用层看的是块设备驱动、I/O 调度器、page cache 管理应用层看的是 FUSE、sdcardfs、SELinux 策略和 App 自身逻辑。举一个真实例子。某机型反馈“从相册删除照片后空间没有释放”乍一看像 Ext4 空间回收问题但其实删除动作发生在 FUSE 层真正的 unlink 发生在底层 Ext4。先用 df 看空间确实没变化再用 lsof 找到还持有文件句柄的进程发现是某个媒体扫描服务一直占着已删除文件的句柄。这既不是 Ext4 的 bug也不是 FUSE 的幻觉是应用未释放句柄。如果直接去修复文件系统方向完全错了。3.3 复现、最小化验证与备份意识文件系统问题最忌讳在真机上反复试错。我的建议是先构造最小复现环境实在复现不了就用相同分区格式在模拟器或开发板上制造一个近似环境把操作聚焦到最小集合。例如怀疑是 fsync 丢失数据就写一个小程序循环 fsync 并掉电测试怀疑是 SELinux 拦截就临时用 setenforce 0 验证再恢复。强调一点任何 e2fsck 上真机或生产环境之前先把分区做成镜像备份或者至少在安全模式下用只读方式检测。fsck 的自动修复模式虽然好用但碰到严重的元数据不一致时也会丢文件而且不会主动提示你丢了哪些。我的原则是“能只读检查就不自动修复能镜像操作就不实体操作”这条救了我很多次。4. 实操案例四类高频问题还原4.1 案例一/data 分区无法挂载现象描述很简单手机 OTA 或强制断电后开机一直停在 Logo 界面logcat 里出现 Failed to mount /data内核日志带 EXT4-fs error 字样。这种问题多半是 /data 分区的元数据在掉电时没有保持一致性superblock 或 journal 异常。正确操作是进 recovery 模式先用只读方式检查。命令大致是 e2fsck -fn /dev/block/bootdevice/by-name/userdata不同平台的设备节点路径不一样但思路一致。如果输出显示 superblock checksum mismatch说明主超级块有问题再用 -b 指定备份超级块例如 e2fsck -b 32768 -fn 设备找到可用块后再做修复。修复时优先 -p 自动修复不行就 -y 全自动应答但前提是已经备份了分区镜像。有条件的可以用 Android 平台对应的 fsck 脚本老机型也有用 fsck.f2fs 或 exfat 的先确认分区格式再选工具。这个案例给我们的教训是OTA 升级或大批量写操作时一定要保证电量充足很多时候挂载失败就是写一半断电导致的。现在大多数新机在升级包写入时会做双分区备份但老机型仍会遇到此类问题预防仍然大于修复。4.2 案例二chmod 报 Operation not permitted这类问题在 Android 11 以上设备上尤其常见。现象是 adb shell 里用 root 权限执行 chmod 777 /storage/emulated/0/Android/data/com.example/files系统直接返回 Operation not permitted。排除了权限位和 SELinux 之后剩下的根源是挂载选项和 FUSE 实现Android/data 路径在部分实现中是由 FUSE 守护进程管理的外部进程哪怕 root直接 chmod 是无效的因为该目录的元数据由 FUSE 逻辑动态生成底层 Ext4 并不存储一个真实的 Linux 目录项。处理方式分两种。如果只是开发调试可以通过 run-as 进到应用沙箱目录操作或者用 adb shell 到 /data/data/com.example 目录那是真正落在 Ext4 上的目录。如果是应用内写入则必须走 App 自己的 File API让系统授予路径访问权限例如 ACTION_OPEN_DOCUMENT_TREE。把这两种方式的差异讲清楚能省掉大量“为什么 root 也不管用”的客服式提问。4.3 案例三/storage/emulated/0/Android/data 下的文件“消失”这是一个在多个大型游戏、阅读器 App 上反复出现的问题。用户会在文件管理器里看到一个包名目录里面明明有资源文件但选择打开时提示找不到或者 App 内显示下载完成去文件管理器里看不到下载文件。实际原因是分区存储的隔离策略App 写入的路径和文件管理器访问的路径可能并不是同一个挂载点视角下的同一份数据。在 Android 11 上/Android/data 目录的内容默认不对第三方文件管理器开放于是出现“数据存在、但你看不见、App 也读不到”的现象。要确认数据是否真的还在磁盘上我习惯用 adb shell 下的 find 和 cat 命令直接访问底层路径要注意的是这类访问在新版本上同样受 SELinux 保护需要以 shell 权限或者 root 权限配合适当的 context。对这个问题的正确解法是引导 App 把重要文件写到公共目录比如 Download、Documents而不是和 App 私有数据混在一起。4.4 案例四磁盘写满后的连锁异常这个案例是日常线上和手机都常见的。系统某个分区满了之后表现不只是“不能写新文件”而是各种进程开始出现奇怪的失败。例如日志服务无法写日志导致组件反复重启数据库写入失败导致应用崩溃甚至系统 server 进程因为无法在 /data 下建临时文件直接进入重启循环。我遇到过一次真实情况某款 Android TV 盒子系统持续卡顿CPU 频繁满载起初以为是性能不足后来发现 /system 或 /data 分区被开机日志和 dump 文件顶到 100%。处理上先用 df 和 du -x -h 定位大目录清掉旧日志后系统恢复正常。但根因是某个内置服务没有做日志轮转磁盘被慢慢吃满。所以线上服务器排障时如果 top 命令看到 CPU 100%第一反应不要只盯进程也要看磁盘 I/O 和空间——很多“CPU 爆满”实际上是 I/O 等待导致的任务堆积。5. 性能问题排查存储 I/O 导致的 CPU 飙高5.1 为什么 I/O 卡顿会表现为 CPU 高占用线上服务器和手机上都有一种现象top 显示 CPU 接近 100%但每个进程的 cpu 占比似乎不高或者 CPU 大量时间在 sys 态。这时候要警惕是不是 I/O 在捣鬼。当存储设备响应慢内核的 I/O 等待会把进程置于不可中断睡眠状态即 D 状态。大量进程排队等待时调度器把 CPU 投给内核线程、JBD2 提交线程、workqueue 等表面看系统 CPU 占用高实际上活都堵在磁盘上。一个简单验证方法看 top 里的 wa 和 D 状态进程数再用 iostat 查看实际读写吞吐。如果 wa 很高就该去检查存储层是磁盘坏道重读还是 ext4 日志频繁提交还是 swap 换页风暴。手机上虽然没有 iostat但可以看 /proc/diskstats、/sys/block/*/stat或者直接抓 systrace 的 CPU 状态来判断。5.2 用 proc 与 tracepoint 组合定位线上或开发板出现这类问题推荐组合命令cat /proc/diskstats 看 IOPS/proc/vmstat 看 pgfault、nr_dirty 等页状态配合 echo t /proc/sysrq-trigger 打印当前所有进程的堆栈找出 D 状态进程聚集的内核函数。如果是 Ext4 相关的堆栈比如 ext4_da_write_begin 或者 jbd2_journal_commit_transaction基本可以锁定是文件系统写路径。更细的可以用 tracepoints比如 perf 或 ftrace 抓 ext4:ext4_sync_file_entry、jbd2:jbd2_commit_transaction、block:block_rq_complete排列它们的时间戳就能看出一次写操作卡在哪个环节。我在 NFS 根文件系统与本地 Ext4 对比时就用这套方法最终查到是 fsync 被每次全量 journal 提交拖慢而把 commit 间隔或日志策略调整后性能立竿见影。5.3 服务器场景的延伸虽然项目标题是 Android但线上服务器“CPU 100%”是所有后端工程师都会遇到的场景内核实测方法几乎通用。区别在于服务器上更常遇到的是根分区被日志写满、数据库文件所在 Ext4 分区的 fsync 频繁、或者磁盘老化后大量 I/O 重试。用同样的思路iostat -x 确认磁盘 util 和 awaitdmesg 看 I/O error再针对性扩容或调整挂载参数。如果是 Ext4 自身问题比如逻辑卷碎片化严重可以先做碎片整理或迁移到新卷。6. 常用命令、工具与避坑清单6.1 命令与工具速查表排查目的命令/工具关键输出与说明查看挂载情况mount确认 ext4/f2fs/sdcardfs/fuse 各层挂载点、权限选项查看内核日志dmesg搜 EXT4-fs error、I/O error、JBD2 warning查看应用日志logcat -b all定位 vold、installd、PackageManager 异常查看容量与 inodedf -h / df -i区分“容量满”与“inode 满”查看文件系统超级块tune2fs -l 设备保留块比例、feature、挂载次数只读检查文件系统e2fsck -fn 设备不要在生产环境直接自动修复修复文件系统e2fsck -pf 设备先镜像再修复谨慎使用 -y查看进程打开文件lsof / /proc/*/fd找出占用已删除文件的进程查看块设备统计cat /proc/diskstats观察读写次数、I/O 错误字段查看内存脏页状态cat /proc/vmstat观察 nr_dirty、pgfault 变化抓取内核堆栈echo t /proc/sysrq-trigger定位 D 状态进程和内核函数查看设备文件信息ls -lZd 路径确认属主、SELinux 标签切换 SELinux 模式setenforce 0/1临时验证 SELinux 是否拦截测试后必须恢复6.2 我踩过的几个典型坑第一个坑是文件系统还挂着就跑 e2fsck。模块加载后某些脚本会从 init 里读到挂载状态直接把检查动作挂到了 rootfs 上。结果就是文件系统被检查工具以读写方式碰过出现大量不一致最后只能重新刷机。正确做法是先把分区 umount或者通过只读方式检查。第二个坑是 -y 自动修复后文件被转移到 lostfound看起来还在但已经丢了原始目录结构。等你发现时往往为时已晚。所以“能只读检查就不自动修复能镜像操作就不实体操作”这条原则我在前面反复强调它是最能保命的一条。第三个坑是忽略 SELinux context。很多人拿到 Permission denied第一反应是 chmod 777改完发现还是不行又去改属主。其实用 ls -lZd 看一眼标签不对直接 chcon 或 restorecon 就解决了。Android 设备上尤其要养成先看上下文的习惯。第四个坑是分区格式不同导致的误判。同一台设备上可能是 data 用 F2FS、system 用 Ext4而 F2FS 的“快速回收”逻辑会表现出可用空间抖动、GC 延迟这和 Ext4 的故障表现很像。先用 mount 确认各分区格式再针对性查问题能少走很多弯路。第五个坑是工具版本不匹配。PC 上的 e2fsck 版本可能比安卓内核的 ext4 feature 旧盲目修复会把新特性当成异常。真机上优先使用 AOSP 自带的 fsck 工具链或者在恢复模式下使用对应平台的工具。选型时注意区分 e2fsck、fsck.exfat、mkfs.f2fs 这些不同工具的平台适配度。最后聊一个习惯排查文件系统问题这几年我最大的感受是真正难的不是命令而是判断“该不该动”。很多故障在信息不完整时看起来都像文件系统损坏但只要先抓日志、看挂载、分层排除大部分“疑难杂症”都能在 30 分钟内定位到真正的层次。尤其是 Android 这种套了 FUSE、SELinux、分区存储的设备层次的划分比底层修复技巧更重要。如果你手头正遇到一个诡异的存储问题不妨先按这篇文章的顺序走一遍先确认分区分层再看空间和 inode再看权限上下文最后才动 fsck。遇到 chmod 报错就怀疑 SELinux遇到文件消失就怀疑 Scoped Storage遇到挂载失败再考虑元数据修复。这套思路不仅适用于 Android 的 Ext4放到服务器、嵌入式设备和 TV 盒子上也完全成立。希望这些踩坑经验能帮你少熬几个夜。