关于磁盘分块存储：

  • ①分块存储的另一种实现模式就是分连续的块，可以想象一下，如果将一个文件存储在连续的磁盘块上面，这样带来的好处是不需要记录每个块的索引再拼接了，类似于内存的操作方式，只要记录一个大小和块的首地址实际上就可以了，但是实际在操作的过程中，会需要对文件进行增加删除和修改，如果采用连续存储，可能只能开辟一个新的磁盘块去存储修改过后的文件（因为前面的都被
    连续的存储占用了），这样会导致一个问题，就是前面的那部分空间类似于变成了一个磁盘的碎片了，只有正好有小于那部分磁盘块大小的文件需要存储时，才能够被利用起来，这种情况显然在文件操作中会非常的频繁，最后的结果可能是导致更大的磁盘浪费。所以文件系统这种非连续存储的方式，实际上是一种经过比较后，基于绝大多数场景是有较好的性能的方式，其中主要针对的是文件系统频繁的增删改的场景（当然这种模式在一些都是很小的文件但是数量很多的场景，也会造成空间浪费，比如文件多数都在2k，但是每次都用4k的块去存储，造成50%的空间浪费。但是这种模式，可以想象一下，将文件从2k编程6k这种处理会非常方便，只需要再链接一个磁盘块就行了，原来的磁盘内容保持不变无需做任何操作。
  • ②针对这种浪费的场景，还是有很多人提出了不同的实现方式，比如试图将块增加到8k但是允许一个块中存储多个文件的内容（即块不仅仅是块地址，块还有偏移量的概念，这种方式其实也只是解决了一定特殊场景的空间浪费的问题，性能应该是下降的，比如2k增加到4k原来不用增加块的，现在由于剩余的2k被其他文件占用了，因此需要额外再去分配一块磁盘块，并写入，显然，写入成本、后续的查询成本都增加了，磁盘容量越来越大的今天，并且多数是读文件的使用场景下，显然这种新的方案并不具有多少优势。
  • ③还有人提出将索引节点信息不单独存储，而是存储在每个具体的磁盘块中，由于索引节点和内容存储在一个磁盘块，索引可以节省一个磁盘块的读取的性能，即便对于高速缓冲的场景来说，也是好事，因为可以节省一次读取缓冲或者读取磁盘块的时间。这个其实是对性能有提
    升的方案，但是会使得整体的结构不像原来那样清晰（将inode存储在专门的区域和将inode分布存储在各个磁盘块中，显然，前者更加容易维护，所以也并没有采纳。