董云舟上周我在整理一台老实验机的时候，要找一个小分区放启动镜像。系统是新的，可我鬼使神差打开磁盘工具列表，往下翻到 mkfs.minix 那一条，旁边一个刚转运维的同事问：现在还有人用这个命令格式化磁盘吗？这问题问得很好。ext4、XFS、Btrfs 随便挑一个都更现代，但 Minix 文件系统以及 mkfs.minix 这条命令，并没有完全从 Linux 生态里消失。它在某些小分区、旧设备兼容、文件系统原理学习场景里，仍然是最顺手的工具之一。
这篇文章我不会只把 mkfs.minix 的参数草草抄一遍。我想用它配合一块真实 U 盘，把从分区、格式化、挂载、验证到问题排查的完整过程走一遍，同时说清楚这条老命令背后的文件系统布局、版本差异和使用边界。内容不排斥新手，运维和做嵌入式的朋友看完可以直接在测试环境抄作业；对文件系统内部结构感兴趣的人，也能从后面的超级块观察里找到一点思路。
1. 一条老命令：mkfs.minix该怎么定位
1.1 它从哪来，为什么Linux还留着
Minix 文件系统来自一个为教学目的开发的操作系统。1987 年这个系统发布时，作者把核心源码写进了教材附录，很多学生都是抱着那本厚书一边读一边敲代码。Linux 诞生前后，开发环境同样跑在 Minix 上，早期的 Linux 内核直接沿用了 Minix 文件系统来管理磁盘。所以你会看到两个“活化石”一直保留到今天：一个是内核里的 minix 文件系统驱动，另一个就是 util-linux 工具箱里的 mkfs.minix。
后来内核社区陆续做出了 ext、ext2 等更强大的文件系统，才逐渐把 Minix 文件系统从日常使用中替换掉。但因为它超级简单，没有复杂日志，没有 B+树目录，没有任何“智能”设计，反而让它变成一个特别适合学习磁盘布局的样本。内核维护者也没有把这段支持和工具删除，一直放在 util-linux 里。
很多新人在 ls /sbin/mkfs* 时会看到这么一串带 mkfs. 前缀的文件：mkfs.ext2、mkfs.ext4、mkfs.xfs、mkfs.fat、mkfs.minix。而 mkfs.minix 正是那一堆“现代选手”里最朴素的一个。它不是用来替代谁的，更像是一把留给特殊场景的小号螺丝刀。
1.2 什么场景下你会想起它
我从实际使用倒推，下面几类情况最值得把它捡起来：
- 做一个超小的启动分区或镜像。比如要给某个嵌入式设备做 32MB、64MB 的独立分区，Minix 文件系统造成的额外开销非常小，结构简单到可以手工推算。
- 需要兼容比较老的系统或内核。极老的内核不一定认识 ext4，但对 Minix v1、v2 往往天生支持。
- 学习文件系统原理。Minix 文件系统的超级块、inode 位图、块位图、数据区布局非常清晰，可以拿着十六进制工具逐个字节看。
- 测试场景里不想引入现代文件系统的“自动行为”。例如有些场景要排除日志、延迟分配等干扰，只验证最基本的读写逻辑。
注意，这些场景都有一个共同点：分区都很小。mkfs.minix 从来不是为了格式化一个几百 GB 的硬盘准备的。如果你手里是 2TB 企业盘，请把命令关上，去用 mkfs.ext4 或 mkfs.xfs；如果你只是想找块小盘做实验，或者要在镜像文件里预先放一个极简文件系统，那就可以继续往下看。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 实操前把磁盘和设备理清楚
2.1 用 lsblk 和设备分区确认目标盘
磁盘操作的底线是先确认设备名，这一步做错了，数据就没了。我找了一块 2GB 的旧 U 盘做实验，插上机器后先执行 lsblk：
bash复制lsblk -o NAME,SIZE,TYPE,TRAN,MOUNTPOINTS
输出里会出现类似下面的一行：
text复制sdb 2G disk usb
我确认它是 sdb 而不是系统盘的 sda。判断依据不能只靠“应该不会错”，我会再看一眼盘符对应的厂商和型号。lsblk 看不到的话，可以用：
bash复制lsblk -o NAME,SIZE,MODEL,TRAN
这样能看清是不是 U 盘。接着用 lsblk -f /dev/sdb 看当前盘上是否已有分区和文件系统签名。旧 U 盘往往残留着其他分区表信息，后面格式化前我会处理掉。
一个我非常推荐的习惯是：在执行任何写操作前，把你的目标设备用一行命令固化下来。
bash复制lsblk /dev/sdb
只要这个输出没有出现 `s