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）在负载高时容易卡死或丢数据。
魔法映像企业网站管理系统
下载
技术上面应用了三层结构，AJAX框架，URL重写等基础的开发。并用了动软的代码生成器及数据访问类，加进了一些自己用到的小功能，算是整理了一些自己的操作类。系统设计上面说不出用什么模式，大体设计是后台分两级分类，设置好一级之后，再设置二级并选择栏目类型，如内容，列表，上传文件，新窗口等。这样就可以生成无限多个二级分类，也就是网站栏目。对于扩展性来说，如果有新的需求可以直接加一个栏目类型并新加功能操作
-
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 大量小文件开始超时。
