文件这玩艺，是顺序存储的。其读写是线性的，依靠偏移量实现效率。这种文件，对于读是没问题的。很多可执行文件、影音文件，都是一次做好，多次读取。基本没什么改变的需要。这种情况下，传统意义的文件确实很好用。C语言的文件函数或者Windows 的文件API基本都能实现得很好。

但某文件如果在读的同时（先不强调读吧！）也是频繁写的（既有增加、也有修改、删除），那对于文件的固定结构来说，简直是毁灭性的。因为文件的本身其实是数组，但为了适应这种频繁而又无法预知未来的写操作，需要有类似链表一样的支持。但因为磁盘是线性而实在的，并不是虚空和立体的，因此在一个线性的序列中，会随着删除有很多碎片产生，同时因为这些碎片的存在也会最后使顺序读取变为不可能，最后只有依赖链表了。本来顺序读写的性能优势，最后被链表的遍历给弄得荡然无存。虽然理论上可以进行文件内部的数据迁移，摸平碎片，但这对小文件或许没什么，如果一个文件达到几百兆（更不用说G、T级了），这样倒腾的代价太大，基本没可能。

以上说还是在一个文件中只有一个链表存在，即该文件的读写最小单元只有一种。这种文件的结构太简单了，通常的文件都不是只有一个结构的，很多文件都是由若干个结构组成的，这样一来每种结构就对应了一个链表，我的天，这样一来这文件的空间分配太让人头疼了。碎片简直成几何级数增加。不知道我说的你们理解不？或者我的想法哪里不对？我是不是有点把问题看得太严重了！？现实中，面对这种情况是怎么处理的？

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课