2. 挂载问题与根文件系统排查2.1 开机无法挂载/data 的典型表现与定位思路那种一觉醒来手机卡在Logo或者开机后反复提示“您的设备内部存储损坏”的场景多半就是/data分区挂载失败。网上搜这个问题的用户非常多但真正说清楚原因的不多。我遇到过一个具体案例用户新买的机器刷了第三方Recovery误操作格式化了分区随后系统提示“你的数据可能已经损坏需要恢复出厂设置”但Recovery里连挂载/data都是只读的。这类问题要先看内核日志确认是设备节点丢失、还是文件系统真的损坏。连接电脑后执行adb shell dmesg | grep -i ext4如果日志里出现EXT4-fs error或者aborting journal基本可以确定是文件系统层面出了问题。常见的原因有这几类意外断电、复位导致日志提交不完整journal 没有正确回放。刷机工具在分区未清除干净时强行写入留下了脏的超级块。长期使用后坏块累积锁住了关键元数据区。用户反复强制重启系统自检时 fscrypt 解密阶段就挂了。确认损坏类型后不要急着格式化。可以先在Recovery里打开终端尝试以只读方式挂载mount -o ro /dev/block/bootdevice/by-name/userdata /data如果只读挂载成功说明文件系统主体结构还在可以用后面提到的e2fsck做离线修复。如果只读都挂载不上那就得考虑超级块备份恢复或者格式化。这里注意一个非常容易踩的坑市面上很多一键刷机工具在/data没坏的情况下也会强制执行format userdata它们只是在fastboot层面执行fastboot format userdata完全不检查数据完整性。我曾经接过一个朋友的机器他只是想解开Bootloader锁结果工具把/data格式化了日志、聊天记录全没了。所以排查前一定要先确认是否是人为格式化不能只盯着硬件故障。2.2 根文件系统挂载与 sync、vfs 的那些事很多做嵌入式Linux或者Android底层开发的朋友都会遇到根文件系统挂载问题。搜索关键词里出现了“嵌入式linux 根文件系统挂载 使用nfs v3”这个和Android的Ext4排查其实互为镜像。在Android设备上根分区/system或/通常也是Ext4或EROFS挂载参数带ro标识。如果开机后挂载失败原因是内核里没有对应的文件系统驱动或者是设备树里分区表偏移不对。排查办法是查看内核命令行和分区布局adb shell cat /proc/cmdline adb shell cat /proc/partitions另外注意sync和vfs的关系。Ext4 默认使用ordered_writeback模式也就是说数据块的写入并不保证在提交点之前刷到物理介质但是元数据例如文件大小、inode记录会先写屏障。很多人误以为只要sync执行了所有缓存就一定落盘其实sync只会把当时已经提交给文件系统层的脏页写回去如果应用层自己在write()后没有调用fsync()那sync也是救不了数据的。混合使用NFS和本地Ext4时这个细节尤其致命。我见过一个自动化脚本场景设备把日志先写入本地/data/local/log再通过NFS挂载远程路径备份。测试人员看到sync执行完就断电结果本地日志文件大小是0远程也是空的。后来发现问题在于脚本直接echo进了重定向没有调fsync。解决办法是写完后执行sync -f /data/local/log/file或者干脆用fdatasync系统调用。在Android底层的VFS层还会有一层fuse或者sdcardfs的封装这就牵扯到下面要说到的/storage/emulated/0/android/data/权限问题。3. /storage/emulated/0/android/data/ 权限问题全解3.1 为什么“无法 chmod”很多开发者在 Debug 某第三方应用时会尝试用 adb 直接修改/storage/emulated/0/android/data/com.xxx/files/下的文件权限然后发现即使root权限也提示operation not permitted。这不是因为没有 root而是因为这条路径是虚拟挂载层——通常情况下/storage/emulated/0是通过 FUSE用户空间文件系统或 sdcardfs 注入的模拟视图。你可以执行mount | grep emulated看下实际情况adb shell mount | grep emulated输出可能是类似/dev/fuse on /storage/emulated type fuse (rw,...,gid9997,mask0700)或者/data/media/0 on /storage/emulated/0 type sdcardfs (rw,...,gid9997,derive_gid)。这两种方式都会在 VFS 层重新映射权限也就是说实际物理存储在/data/media/0sdcardfs或/data/user/0/...FUSE背后但你在虚拟层看到的对应用户ID是u0_a123组是sdcard_rw。底层是 Ext4 的权限管理但上层核对权限时用一套模拟的 POSIX 权限所以chmod 777会让上层模型认为你是越权操作从而拒绝。这种设计是刻意为之因为 Android 的存储权限模型基于fs_ident和gid做访问控制而非传统 Linux 的uid/gid。普通应用只能访问/storage/emulated/0/Android/data/自己的包名和/storage/emulated/0/Android/obb/自己包名目录其权限是通过fuse_id分配的不是靠 chmod 改变的。如果你真的需要修改文件属主或目录权限需要绕开虚拟层直接访问真实底层# 直接进入/data/media/0/Android/data/com.xxx/files/ adb shell su cd /data/media/0/Android/data/com.xxx/files/ chown media_rw:media_rw .注意这需要SELinux处于permissive模式否则即使 root 也会被审计拒绝。这里提醒一句千万不要用adb shell chmod -R /storage/emulated/0这类命令去强行递归授权我在测试机上试过一次导致整个存储的访问模型全部错乱最后只能备份数据格式化。3.2 应用下载文件“找不到”的内幕热搜词里有几个特别典型的路径比如/storage/emulated/0/android/data/com.tencent.tmgp.sgame/files/pandora/pr这类目录是某游戏的自更新分包目录或者com.mi.health的日志目录。用户侧最常见的反馈是手机存储空间被占用但自己看不到文件在哪或者 App 内能打开预览、下载但用系统文件管理器找不到。这里的基本逻辑/data/media/0/Android/data/包名在用户视图里是存在的但系统文件管理器会主动隐藏这个目录。换言之它存在于 Ext4 的真实分区上但虚拟文件系统做了豁免过滤。所以“找不到”不是文件系统问题而是 Android 的文件安全策略在作祟。如果你用 adb 访问却看不到可以执行adb shell ls -l /storage/emulated/0/Android/data/有时候目录为空或列表缺失可能是因为该目录确实被清理了或者共享存储索引还没刷新。可以通过重挂载 FUSE 来让索引重建adb shell stop; adb shell start这个方法能解决90%的“目录明明有内容但列表为空”问题。如果重启还不能生效那就要查一下是不是 FUSE 文件句柄泄漏多见于某些应用频繁打开关闭文件造成僵尸节点堆积导致readdir超时。这时候logcat -s StorageManager会给出具体提示。另外注意区分/storage/emulated/0/Android/data/包名和/data/data/包名。前者是用户可见分区的应用私有目录后者是/data分区的应用私有目录App 通常写入context.getExternalFilesDir()和context.getFilesDir()分别对应。如果文件写入后无法找到先确认代码里用的是哪个方法别把getExternalFilesDir()的文件误认为/data/data那自然找错地方。4. 数据损坏与恢复实战4.1 意外断电后 Ext4 文件系统损坏的表现与修复方法一个很典型的场景手机在升级过程或恢复出厂设置时突然没电再开机卡在启动动画。此时 adb 还能连上但 shell 下输入mount会发现/data挂载失败。我用过一个具体的修复流程记录下来作为参考。第一步进入 recovery 模式通过 adb 连接查看当前挂载情况adb devices adb shell mount | grep data如果没有任何输出说明/data根本没挂载。接着识别设备节点ls -l /dev/block/bootdevice/by-name/不同厂商命名不同常见的是userdata。我遇到过某款麒麟芯片的设备命名是suserdata如果直接写userdata会提示找不到设备所以最好用dmesg | grep userdata来确认真实名称。第二步对文件系统做校验。注意此时不要直接加-f单参数因为有些损坏只发生在元数据块用-p自动修复可能忽略。我习惯先只读扫描一遍看看具体错误e2fsck -fn /dev/block/bootdevice/by-name/userdata-n是只读模式不会写入任何修改风险最低。如果打印出一些Inode N is read but has corrupt file name之类的信息说明文件名字节错乱多半是日志中的 dirent 条目写了一半。此时可以再用可写模式修复e2fsck -fy /dev/block/bootdevice/by-name/userdata注意-y代表所有问题都自动回答 yes修复过程中丢失的文件碎片会被放到lostfound目录。这一步需要较长时间具体取决于分区大小我修复 256GB 的/data用时约 40 分钟。这里有个经验如果只提示Journal superblock异常可以直接用e2fsck -fy完成回滚。但如果提示Block bitmap不一致说明文件系统结构性损毁光靠 e2fsck 并不保险宁可先dd备份整分区再修复也不要直接格式化。另外修完文件系统后很多机器还有一层 FBEFile-Based Encryption加密。需要重新用加密密钥解锁用户数据通常 recovery 中挂载/data时还会提示输入密码。这个涉及到 keystore 状态如果/metadata分区也损坏那就只能丢失数据了。4.2 日志目录积压导致 inode 耗尽很多时候应用会不断写日志比如小米健康类的log/xiaofit.main.log一个文件不断追加不会撑爆 inode。但是有些应用尤其游戏引擎会切分文件一个 session 生成一个日志文件久而久之小文件数量几十万直接把/data分区的 inode 耗尽。表现是df -h显示空间还有 20 个 GB但创建文件时报No space left on device并且dmesg中会有Ext4: No space left for inserting file system metadata。这就是 inode 耗尽。排查命令adb shell df -i /data查看IFree列是否接近 0。同时用find统计小文件数量adb shell find /data/media/0/Android/data/ -type f | wc -l如果数量超过十万基本就是 inode 告警。清理方法不是一个个删而是直接定位大目录adb shell du -sh /data/media/0/Android/data/com.tencent.tmgp.sgame/然后进入该目录找到类似pandora/pr/cache的子目录直接rm -rf。注意有些文件正在被进程占用删除后空间并不会释放需要先停止对应应用adb shell am force-stop com.tencent.tmgp.sgame之后再删。这里也提醒一下Ext4 创建文件时 inode 数量是初始化分区时固定的不是动态生成。如果你知道自己会长时间跑大量小文件最好在用mkfs.ext4格式化分区时直接指定-N 20000000预留足够 inode。或者干脆换用 F2FS 这种动态 inode 的文件系统现在很多厂商新机型都已经默认 F2FS就是考虑到了这一点。5. 工具与其他文件系统对比5.1 常用工具集与命令速查排查 Android Ext4 问题我实际用到最多的命令组合整理如下目的命令查看分区挂载情况adb shell mount查看内核错误adb shell dmesg查看文件系统特征adb shell dumpe2fs -h /dev/block/bootdevice/by-name/userdata只读检查adb shell e2fsck -fn /dev/block/bootdevice/by-name/userdata强制修复adb shell e2fsck -fy /dev/block/bootdevice/by-name/userdata查看inode使用率adb shell df -i /data查看坏块adb shell badblocks -v /dev/block/bootdevice/by-name/userdata挂载为只读调试adb shell mount -o ro,remount /data重置FUSE索引adb shell stop; adb shell start除了这些命令行工具现代 Android 自带的storage_stats服务也可以辅助排查。通过adb shell dumpsys mount可以看到与挂载点相关的所有进程和计数。我用过几个第三方的 ext4 检查工具比如 Linux 下的testdisk、photorec也能直接读取userdata.img镜像对于删除恢复有一定帮助。注意不是在手机里跑而是把分区dd出来成一个.img文件插在电脑上操作dd if/dev/block/bootdevice/by-name/userdata of/sdcard/userdata.img bs4M然后在电脑上用testdisk分析这个镜像。5.2 对比 littlefs、F2FS 与 Ext4搜索词里提到platformio 使用闪存文件系统littlefs。LittleFS 是嵌入式设备上常用的一种日志型闪存文件系统针对 NOR/NAND Flash 的掉电保护做了优化而 Ext4 是为块设备设计的。很多刚接触嵌入式开发的朋友以为 littlefs 和 ext4 可以用同一套排查逻辑其实差异非常大。简单对比下项目Ext4F2FSlittlefs适用设备大容量块设备大容量NAND/嵌入式小容量NOR/SPI Flash掉电保护依赖Journal依赖checkpoint本身具备掉电恢复分区初始化速度慢中快支持inode预分配固定动态动态Android常见用途/system、/data部分老机型/data新机型外挂存储、固件系统排查 littlefs 问题就不能再用e2fsck而是用mlf或者官方提供的littlefs-fuse工具。这里只提一句不展开说避免跑题。重点还是 Ext4。5.3 文件系统操作中速度和稳定性的平衡技巧我遇到过用户在.ext4.img镜像中导入导出大量文件时卡死了原因很简单文件系统调试时用了loop挂载但没有加discard和nobarrier参数导致每个文件写入都要触发阈值检查。挂载时建议区分环境开发调试数据不敏感用mount -o loop,datawriteback,barrier0 /test.img /mnt写入速度提升明显但掉电可能损坏数据。生产环境数据宝贵用mount -o dataordered,barrier1保证元数据先落盘。在 Android 设备上极少直接手动挂载镜像更多是配合fastboot刷写。刷写镜像时如果出现FAILED (remote: invalid ext4 image)很可能是镜像头部或超级块信息被修改过检查一下dumpe2fs的输出中分区容量是否与目标分区一致。6. 排障清单与避坑指南6.1 排查前必做的准备动手之前第一件事永远是备份。不要觉得自己设备 root 过就可以放心Ext4 问题一旦走上e2fsck -fy丢失数据的风险是实打实的。我的做法是用adb backup或者dd方式先备份用户分区。虽然 128GB 的备份很慢但值得。备份完成后还要确认设备当前 SELinux 状态adb shell getenforce。如果是Enforcing很多底层修复命令会被拦截可以执行adb shell setenforce 0临时进入Permissive。重启后恢复注意不要在正式环境长期使用否则后续系统审计会乱。6.2 常见问题速查表现象可能原因排查命令解决办法开机提示内部存储损坏Ext4 journal异常dmesg | grep ext4e2fsck -fy明明有空间却写入失败inode耗尽df -i /data清理小文件chmod /storage/emulated/0 报 operation not permittedFUSE/sdcardfs虚拟层权限mount | grep emulated直接在/data/media/0下操作挂载提示 read-only file system文件系统脏未正确修复mount先e2fsck再remount删除文件后空间不释放进程占用或FUSE延迟写回lsof | grep deleted停止相关应用再删应用下载文件找不到App私有目录被文件管理器隐藏ls /data/media/0/Android/data/手动进入或调整FileProvider策略这张表是基于我实际接过的咨询整理出来的能覆盖大部分日常问题和一部分深度疑难。6.3 实际操作体会与一个小技巧最后再分享一个个人经验总结的排查诀窍。很多人遇到/storage/emulated/0/下的权限问题总想通过chmod或chown直接改但改完以后状态不持久重启又变回去了。这不是没保存而是 FUSE 上层的umask和gid由挂载选项控制不归你管。如果你只是想在开发阶段让自己的应用访问别人的android/data目录文件比较通行的方式有两种一是把应用的targetSdk临时降到 29 或以下避开分区存储强制模式二是通过 adb 授权adb shell appops set com.你的包名 MANAGE_EXTERNAL_STORAGE allow这个操作不会改变任何文件系统权限只是在应用管理器层面提升的访问能力。用这个方法测试完记得收回去不然文件系统审计会亮红灯。对于真正要排查底层 Ext4 问题的同行我再啰嗦一句不要一上来就mkfs.ext4先dump2fs -h看看超级块信息再e2fsck走一遍很多所谓“损坏”其实只是 dirty 标志没清干净。官方文档里总强调先备份实际操作中很多人做不到但越是关键数据越要在动手前留一手。毕竟 Ext4 问题虽然看着吓人大多数时候只要找到具体错误码修复路径都是标准的最怕的是上来一顿格式化数据没了才想起后悔。
2. 挂载问题与根文件系统排查2.1 开机无法挂载/data 的典型表现与定位思路那种一觉醒来手机卡在Logo或者开机后反复提示“您的设备内部存储损坏”的场景多半就是/data分区挂载失败。网上搜这个问题的用户非常多但真正说清楚原因的不多。我遇到过一个具体案例用户新买的机器刷了第三方Recovery误操作格式化了分区随后系统提示“你的数据可能已经损坏需要恢复出厂设置”但Recovery里连挂载/data都是只读的。这类问题要先看内核日志确认是设备节点丢失、还是文件系统真的损坏。连接电脑后执行adb shell dmesg | grep -i ext4如果日志里出现EXT4-fs error或者aborting journal基本可以确定是文件系统层面出了问题。常见的原因有这几类意外断电、复位导致日志提交不完整journal 没有正确回放。刷机工具在分区未清除干净时强行写入留下了脏的超级块。长期使用后坏块累积锁住了关键元数据区。用户反复强制重启系统自检时 fscrypt 解密阶段就挂了。确认损坏类型后不要急着格式化。可以先在Recovery里打开终端尝试以只读方式挂载mount -o ro /dev/block/bootdevice/by-name/userdata /data如果只读挂载成功说明文件系统主体结构还在可以用后面提到的e2fsck做离线修复。如果只读都挂载不上那就得考虑超级块备份恢复或者格式化。这里注意一个非常容易踩的坑市面上很多一键刷机工具在/data没坏的情况下也会强制执行format userdata它们只是在fastboot层面执行fastboot format userdata完全不检查数据完整性。我曾经接过一个朋友的机器他只是想解开Bootloader锁结果工具把/data格式化了日志、聊天记录全没了。所以排查前一定要先确认是否是人为格式化不能只盯着硬件故障。2.2 根文件系统挂载与 sync、vfs 的那些事很多做嵌入式Linux或者Android底层开发的朋友都会遇到根文件系统挂载问题。搜索关键词里出现了“嵌入式linux 根文件系统挂载 使用nfs v3”这个和Android的Ext4排查其实互为镜像。在Android设备上根分区/system或/通常也是Ext4或EROFS挂载参数带ro标识。如果开机后挂载失败原因是内核里没有对应的文件系统驱动或者是设备树里分区表偏移不对。排查办法是查看内核命令行和分区布局adb shell cat /proc/cmdline adb shell cat /proc/partitions另外注意sync和vfs的关系。Ext4 默认使用ordered_writeback模式也就是说数据块的写入并不保证在提交点之前刷到物理介质但是元数据例如文件大小、inode记录会先写屏障。很多人误以为只要sync执行了所有缓存就一定落盘其实sync只会把当时已经提交给文件系统层的脏页写回去如果应用层自己在write()后没有调用fsync()那sync也是救不了数据的。混合使用NFS和本地Ext4时这个细节尤其致命。我见过一个自动化脚本场景设备把日志先写入本地/data/local/log再通过NFS挂载远程路径备份。测试人员看到sync执行完就断电结果本地日志文件大小是0远程也是空的。后来发现问题在于脚本直接echo进了重定向没有调fsync。解决办法是写完后执行sync -f /data/local/log/file或者干脆用fdatasync系统调用。在Android底层的VFS层还会有一层fuse或者sdcardfs的封装这就牵扯到下面要说到的/storage/emulated/0/android/data/权限问题。3. /storage/emulated/0/android/data/ 权限问题全解3.1 为什么“无法 chmod”很多开发者在 Debug 某第三方应用时会尝试用 adb 直接修改/storage/emulated/0/android/data/com.xxx/files/下的文件权限然后发现即使root权限也提示operation not permitted。这不是因为没有 root而是因为这条路径是虚拟挂载层——通常情况下/storage/emulated/0是通过 FUSE用户空间文件系统或 sdcardfs 注入的模拟视图。你可以执行mount | grep emulated看下实际情况adb shell mount | grep emulated输出可能是类似/dev/fuse on /storage/emulated type fuse (rw,...,gid9997,mask0700)或者/data/media/0 on /storage/emulated/0 type sdcardfs (rw,...,gid9997,derive_gid)。这两种方式都会在 VFS 层重新映射权限也就是说实际物理存储在/data/media/0sdcardfs或/data/user/0/...FUSE背后但你在虚拟层看到的对应用户ID是u0_a123组是sdcard_rw。底层是 Ext4 的权限管理但上层核对权限时用一套模拟的 POSIX 权限所以chmod 777会让上层模型认为你是越权操作从而拒绝。这种设计是刻意为之因为 Android 的存储权限模型基于fs_ident和gid做访问控制而非传统 Linux 的uid/gid。普通应用只能访问/storage/emulated/0/Android/data/自己的包名和/storage/emulated/0/Android/obb/自己包名目录其权限是通过fuse_id分配的不是靠 chmod 改变的。如果你真的需要修改文件属主或目录权限需要绕开虚拟层直接访问真实底层# 直接进入/data/media/0/Android/data/com.xxx/files/ adb shell su cd /data/media/0/Android/data/com.xxx/files/ chown media_rw:media_rw .注意这需要SELinux处于permissive模式否则即使 root 也会被审计拒绝。这里提醒一句千万不要用adb shell chmod -R /storage/emulated/0这类命令去强行递归授权我在测试机上试过一次导致整个存储的访问模型全部错乱最后只能备份数据格式化。3.2 应用下载文件“找不到”的内幕热搜词里有几个特别典型的路径比如/storage/emulated/0/android/data/com.tencent.tmgp.sgame/files/pandora/pr这类目录是某游戏的自更新分包目录或者com.mi.health的日志目录。用户侧最常见的反馈是手机存储空间被占用但自己看不到文件在哪或者 App 内能打开预览、下载但用系统文件管理器找不到。这里的基本逻辑/data/media/0/Android/data/包名在用户视图里是存在的但系统文件管理器会主动隐藏这个目录。换言之它存在于 Ext4 的真实分区上但虚拟文件系统做了豁免过滤。所以“找不到”不是文件系统问题而是 Android 的文件安全策略在作祟。如果你用 adb 访问却看不到可以执行adb shell ls -l /storage/emulated/0/Android/data/有时候目录为空或列表缺失可能是因为该目录确实被清理了或者共享存储索引还没刷新。可以通过重挂载 FUSE 来让索引重建adb shell stop; adb shell start这个方法能解决90%的“目录明明有内容但列表为空”问题。如果重启还不能生效那就要查一下是不是 FUSE 文件句柄泄漏多见于某些应用频繁打开关闭文件造成僵尸节点堆积导致readdir超时。这时候logcat -s StorageManager会给出具体提示。另外注意区分/storage/emulated/0/Android/data/包名和/data/data/包名。前者是用户可见分区的应用私有目录后者是/data分区的应用私有目录App 通常写入context.getExternalFilesDir()和context.getFilesDir()分别对应。如果文件写入后无法找到先确认代码里用的是哪个方法别把getExternalFilesDir()的文件误认为/data/data那自然找错地方。4. 数据损坏与恢复实战4.1 意外断电后 Ext4 文件系统损坏的表现与修复方法一个很典型的场景手机在升级过程或恢复出厂设置时突然没电再开机卡在启动动画。此时 adb 还能连上但 shell 下输入mount会发现/data挂载失败。我用过一个具体的修复流程记录下来作为参考。第一步进入 recovery 模式通过 adb 连接查看当前挂载情况adb devices adb shell mount | grep data如果没有任何输出说明/data根本没挂载。接着识别设备节点ls -l /dev/block/bootdevice/by-name/不同厂商命名不同常见的是userdata。我遇到过某款麒麟芯片的设备命名是suserdata如果直接写userdata会提示找不到设备所以最好用dmesg | grep userdata来确认真实名称。第二步对文件系统做校验。注意此时不要直接加-f单参数因为有些损坏只发生在元数据块用-p自动修复可能忽略。我习惯先只读扫描一遍看看具体错误e2fsck -fn /dev/block/bootdevice/by-name/userdata-n是只读模式不会写入任何修改风险最低。如果打印出一些Inode N is read but has corrupt file name之类的信息说明文件名字节错乱多半是日志中的 dirent 条目写了一半。此时可以再用可写模式修复e2fsck -fy /dev/block/bootdevice/by-name/userdata注意-y代表所有问题都自动回答 yes修复过程中丢失的文件碎片会被放到lostfound目录。这一步需要较长时间具体取决于分区大小我修复 256GB 的/data用时约 40 分钟。这里有个经验如果只提示Journal superblock异常可以直接用e2fsck -fy完成回滚。但如果提示Block bitmap不一致说明文件系统结构性损毁光靠 e2fsck 并不保险宁可先dd备份整分区再修复也不要直接格式化。另外修完文件系统后很多机器还有一层 FBEFile-Based Encryption加密。需要重新用加密密钥解锁用户数据通常 recovery 中挂载/data时还会提示输入密码。这个涉及到 keystore 状态如果/metadata分区也损坏那就只能丢失数据了。4.2 日志目录积压导致 inode 耗尽很多时候应用会不断写日志比如小米健康类的log/xiaofit.main.log一个文件不断追加不会撑爆 inode。但是有些应用尤其游戏引擎会切分文件一个 session 生成一个日志文件久而久之小文件数量几十万直接把/data分区的 inode 耗尽。表现是df -h显示空间还有 20 个 GB但创建文件时报No space left on device并且dmesg中会有Ext4: No space left for inserting file system metadata。这就是 inode 耗尽。排查命令adb shell df -i /data查看IFree列是否接近 0。同时用find统计小文件数量adb shell find /data/media/0/Android/data/ -type f | wc -l如果数量超过十万基本就是 inode 告警。清理方法不是一个个删而是直接定位大目录adb shell du -sh /data/media/0/Android/data/com.tencent.tmgp.sgame/然后进入该目录找到类似pandora/pr/cache的子目录直接rm -rf。注意有些文件正在被进程占用删除后空间并不会释放需要先停止对应应用adb shell am force-stop com.tencent.tmgp.sgame之后再删。这里也提醒一下Ext4 创建文件时 inode 数量是初始化分区时固定的不是动态生成。如果你知道自己会长时间跑大量小文件最好在用mkfs.ext4格式化分区时直接指定-N 20000000预留足够 inode。或者干脆换用 F2FS 这种动态 inode 的文件系统现在很多厂商新机型都已经默认 F2FS就是考虑到了这一点。5. 工具与其他文件系统对比5.1 常用工具集与命令速查排查 Android Ext4 问题我实际用到最多的命令组合整理如下目的命令查看分区挂载情况adb shell mount查看内核错误adb shell dmesg查看文件系统特征adb shell dumpe2fs -h /dev/block/bootdevice/by-name/userdata只读检查adb shell e2fsck -fn /dev/block/bootdevice/by-name/userdata强制修复adb shell e2fsck -fy /dev/block/bootdevice/by-name/userdata查看inode使用率adb shell df -i /data查看坏块adb shell badblocks -v /dev/block/bootdevice/by-name/userdata挂载为只读调试adb shell mount -o ro,remount /data重置FUSE索引adb shell stop; adb shell start除了这些命令行工具现代 Android 自带的storage_stats服务也可以辅助排查。通过adb shell dumpsys mount可以看到与挂载点相关的所有进程和计数。我用过几个第三方的 ext4 检查工具比如 Linux 下的testdisk、photorec也能直接读取userdata.img镜像对于删除恢复有一定帮助。注意不是在手机里跑而是把分区dd出来成一个.img文件插在电脑上操作dd if/dev/block/bootdevice/by-name/userdata of/sdcard/userdata.img bs4M然后在电脑上用testdisk分析这个镜像。5.2 对比 littlefs、F2FS 与 Ext4搜索词里提到platformio 使用闪存文件系统littlefs。LittleFS 是嵌入式设备上常用的一种日志型闪存文件系统针对 NOR/NAND Flash 的掉电保护做了优化而 Ext4 是为块设备设计的。很多刚接触嵌入式开发的朋友以为 littlefs 和 ext4 可以用同一套排查逻辑其实差异非常大。简单对比下项目Ext4F2FSlittlefs适用设备大容量块设备大容量NAND/嵌入式小容量NOR/SPI Flash掉电保护依赖Journal依赖checkpoint本身具备掉电恢复分区初始化速度慢中快支持inode预分配固定动态动态Android常见用途/system、/data部分老机型/data新机型外挂存储、固件系统排查 littlefs 问题就不能再用e2fsck而是用mlf或者官方提供的littlefs-fuse工具。这里只提一句不展开说避免跑题。重点还是 Ext4。5.3 文件系统操作中速度和稳定性的平衡技巧我遇到过用户在.ext4.img镜像中导入导出大量文件时卡死了原因很简单文件系统调试时用了loop挂载但没有加discard和nobarrier参数导致每个文件写入都要触发阈值检查。挂载时建议区分环境开发调试数据不敏感用mount -o loop,datawriteback,barrier0 /test.img /mnt写入速度提升明显但掉电可能损坏数据。生产环境数据宝贵用mount -o dataordered,barrier1保证元数据先落盘。在 Android 设备上极少直接手动挂载镜像更多是配合fastboot刷写。刷写镜像时如果出现FAILED (remote: invalid ext4 image)很可能是镜像头部或超级块信息被修改过检查一下dumpe2fs的输出中分区容量是否与目标分区一致。6. 排障清单与避坑指南6.1 排查前必做的准备动手之前第一件事永远是备份。不要觉得自己设备 root 过就可以放心Ext4 问题一旦走上e2fsck -fy丢失数据的风险是实打实的。我的做法是用adb backup或者dd方式先备份用户分区。虽然 128GB 的备份很慢但值得。备份完成后还要确认设备当前 SELinux 状态adb shell getenforce。如果是Enforcing很多底层修复命令会被拦截可以执行adb shell setenforce 0临时进入Permissive。重启后恢复注意不要在正式环境长期使用否则后续系统审计会乱。6.2 常见问题速查表现象可能原因排查命令解决办法开机提示内部存储损坏Ext4 journal异常dmesg | grep ext4e2fsck -fy明明有空间却写入失败inode耗尽df -i /data清理小文件chmod /storage/emulated/0 报 operation not permittedFUSE/sdcardfs虚拟层权限mount | grep emulated直接在/data/media/0下操作挂载提示 read-only file system文件系统脏未正确修复mount先e2fsck再remount删除文件后空间不释放进程占用或FUSE延迟写回lsof | grep deleted停止相关应用再删应用下载文件找不到App私有目录被文件管理器隐藏ls /data/media/0/Android/data/手动进入或调整FileProvider策略这张表是基于我实际接过的咨询整理出来的能覆盖大部分日常问题和一部分深度疑难。6.3 实际操作体会与一个小技巧最后再分享一个个人经验总结的排查诀窍。很多人遇到/storage/emulated/0/下的权限问题总想通过chmod或chown直接改但改完以后状态不持久重启又变回去了。这不是没保存而是 FUSE 上层的umask和gid由挂载选项控制不归你管。如果你只是想在开发阶段让自己的应用访问别人的android/data目录文件比较通行的方式有两种一是把应用的targetSdk临时降到 29 或以下避开分区存储强制模式二是通过 adb 授权adb shell appops set com.你的包名 MANAGE_EXTERNAL_STORAGE allow这个操作不会改变任何文件系统权限只是在应用管理器层面提升的访问能力。用这个方法测试完记得收回去不然文件系统审计会亮红灯。对于真正要排查底层 Ext4 问题的同行我再啰嗦一句不要一上来就mkfs.ext4先dump2fs -h看看超级块信息再e2fsck走一遍很多所谓“损坏”其实只是 dirty 标志没清干净。官方文档里总强调先备份实际操作中很多人做不到但越是关键数据越要在动手前留一手。毕竟 Ext4 问题虽然看着吓人大多数时候只要找到具体错误码修复路径都是标准的最怕的是上来一顿格式化数据没了才想起后悔。
