ext4因稳定性、日志机制和断电容错能力成为多数服务器默认选择，适合数据库等写入频繁但不追求极致吞吐的场景；禁用日志或激进调参易致数据丢失，XFS在超大文件、海量小文件或需在线扩容时更优；Btrfs快照等功能可用，但RAID5/6等高危功能慎用；tmpfs和overlayfs非磁盘文件系统，配置不当易引发OOM或启动失败；文件系统选型关键在于匹配业务IO特征而非单纯追新。

ext4 为什么还是大多数服务器的默认选择

因为它的稳定性、日志机制和对突发断电的容错能力在生产环境中经得起考验，尤其适合数据库、文件共享等写入频繁但不追求极致吞吐的场景。

• mkfs.ext4 -O ^has_journal /dev/sdb1 这种禁用日志的操作看似能提速，实则让文件系统在崩溃后大概率无法挂载，除非你明确知道自己在做无持久性要求的临时盘
• 默认的 data=ordered 模式平衡了性能与数据安全；换成 data=writeback 虽快，但断电时可能丢失刚写入的文件内容（不只是元数据）
• 大文件连续写入时，tune2fs -o journal_data_writeback /dev/sdb1 配合挂载参数可微调，但别在根分区或 MySQL 数据目录上乱试

XFS 在什么情况下必须考虑

当单个文件超过几十 GB、目录里有千万级小文件、或者需要在线扩容时，XFS 的扩展性和元数据处理效率明显优于 ext4。

• xfs_info /mnt/data 查看实际块大小和 inode 分配策略，ino64 和 bigtime 特性开启后才能支持超大时间戳和 inode 号，旧内核（如 CentOS 7 默认）可能不识别
• xfs_growfs /mnt/data 支持在线扩容，但前提是底层块设备（如 LVM 逻辑卷）已先扩容，否则命令会静默失败
• 不支持 shrink —— xfs_growfs 只能变大，不能变小；想缩容得先 dump + mkfs + restore

Btrfs 的“稳定”边界在哪

它不是不能用，而是得清楚哪些功能踩了线就会掉进坑里：快照、子卷、透明压缩这些没问题；RAID5/6、跨设备平衡（btrfs balance）、自动碎片整理（autodefrag）在负载高时容易卡死或丢数据。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• btrfs filesystem usage /mnt/btrfs 比 df 更准，因为 Btrfs 的空间是按块组动态分配的，df 经常误报“满”
• 启用 compress=zstd 挂载选项对文本类日志有效，但对已压缩文件（如 .zip、.jpg）反而增加 CPU 开销且不省空间
• btrfs scrub start /mnt/btrfs 应定期运行来发现静默损坏，但别在 SSD 上高频执行——它会触发大量读放大

tmpfs 和 overlayfs 不是“类型”，但常被误当成文件系统选型

它们不落盘，也不归类于磁盘文件系统，但配置错误会导致服务莫名 OOM 或容器启动失败。

• mount -t tmpfs -o size=2G tmpfs /run/myapp 中的 size 是硬上限，超出直接 ENOSPC；而 nr_inodes 不设的话，默认只给 16K inode，放几万个 socket 文件就撑爆
• Docker 默认用 overlay2，但若底层是 ext4 且没开 dir_index 和 filetype 特性，docker build 多层镜像时会慢 3 倍以上
• /proc/mounts 里看到 overlay 类型，不代表你在用 overlayfs——可能是旧内核或容器运行时 fallback 到了 aufs，得看 cat /sys/module/overlay/version

文件系统不是越新越好，也不是参数调得越激进越快。真正难的是在业务增长过程中，预判哪类 IO 模式会最先暴露底层限制——比如从 ext4 切到 XFS 往往不是因为容量不够，而是 rename 大量小文件开始超时。