3. QNX4文件系统（旧版兼容）：遗留系统的选择，性能与功能的权衡

聊到QNX4文件系统，我得先坦白一件事。我入行那会儿，QNX4还是主流。那时候没有现在这么多花哨的选择，QNX4 FS就是默认选项。现在回头看，它确实老了，但在某些场景下，你不得不跟它打交道。

说白了，QNX4文件系统是为80年代末90年代初的硬件设计的。那时候内存按KB算，CPU主频几十兆赫兹。它很轻量，很可靠，但功能上确实跟不上时代了。

3.1 它到底是个什么结构？

QNX4文件系统用的是类Unix的树形结构，但底层实现完全不同。它没有用传统的inode机制，而是用了自己的一套「节点+记录」的方式。

每个文件或目录在磁盘上对应一个节点（node）。节点里存的是元数据——文件名、大小、时间戳、权限这些。真正的数据块则通过记录（record）链表串起来。

嗯，这里要注意：QNX4的节点大小是固定的，我记得是256字节。这意味着单个目录下能放的文件数量有限制。我遇到过有人在一个目录下塞了上万个文件，结果系统响应慢得像蜗牛。

3.2 性能表现：快，但有代价

QNX4文件系统的读取性能其实相当不错。为什么？因为它结构简单。没有日志开销，没有复杂的B树索引，就是直来直去的链表遍历。对于顺序读写，它的吞吐量在当年是顶尖的。

但随机读写就有点尴尬了。你想想看，链表结构意味着你要找一个数据块，得从头开始遍历。文件越大，碎片越多，性能下降越明显。

我记得有一次帮客户调一个数据采集系统。他们用QNX4 FS存实时数据，每天产生几百个小文件。跑了三个月后，系统启动时间从30秒变成了5分钟。一查，目录节点下的记录链表已经长得不成样子了。

场景	QNX4 FS	现代FS（如Power-Safe）
顺序读（大文件）	优秀	优秀
随机读（小文件）	一般	优秀
大量小文件创建	差	良好
碎片整理	需要手动	自动/低碎片
崩溃恢复	fsck修复	日志回滚

3.3 功能上的取舍

QNX4文件系统缺少很多现代文件系统的特性。我列几个你可能会在意的：

• 没有日志功能——突然断电？恭喜你，下次启动得跑fsck。文件越多，fsck越慢。我曾经见过一个500MB的QNX4分区，fsck跑了40分钟。
• 没有软链接——只有硬链接。而且硬链接不能跨文件系统。
• 没有扩展属性——你想给文件加个自定义标签？没门。
• 权限模型简单——只有读、写、执行三组权限，没有ACL。

3.4 什么时候该选它？

说实话，除非你被绑在遗留系统上，否则我不建议在新项目里用QNX4文件系统。但现实是，很多工业设备、军工系统、老旧的嵌入式设备还在跑QNX4。你没法把整个系统重写一遍。

我总结了几种必须用QNX4 FS的场景：

1. 硬件太老——CPU是486、Pentium级别的，内存不到16MB。现代文件系统的开销它扛不住。
2. 二进制兼容性要求——现有应用程序直接读写QNX4分区，改代码成本太高。
3. 双启动或多系统共存——QNX4和QNX6（或其它OS）共享磁盘分区。
4. 极简系统——不需要日志、权限控制等高级功能，只要一个能存文件的底层。

3.5 迁移路径：从QNX4到现代FS

如果你有预算和时间，我强烈建议考虑迁移。QNX 6.x（现在叫QNX Neutrino）支持多种文件系统，包括QNX4兼容模式。你可以这样做：

• 在QNX Neutrino下挂载QNX4分区（只读或读写）
• 逐步将数据复制到Power-Safe或QNX6 FS分区
• 修改应用程序，使用新的挂载点路径
• 最终卸载QNX4分区，释放磁盘空间

嗯，这个过程说起来简单，做起来可能很痛苦。尤其是那些直接操作磁盘块的老程序，你得仔细检查它们有没有硬编码的偏移量或扇区号。

我记得有个客户，他们的设备控制程序直接通过devb-xxx驱动读写QNX4分区的原始块设备。迁移时发现代码里到处都是lseek到固定位置的调用。改了一个月才搞定。

所以，如果你现在还在维护QNX4 FS的系统，趁早规划迁移。别等到硬件坏了、磁盘坏了、或者系统彻底跑不动了再动手。那时候就晚了。

最后说一句：QNX4文件系统不是不能用，但你要清楚它的边界在哪里。用对了地方，它是个可靠的老伙计。用错了，它就是个坑。你自己掂量着办。