第六章 APO文件目录系统

 

            第六章  APO文件目录系统与磁盘文件管理类的实现

 

追求：简单啊！巨大啊！超光速啊！爽啊！

以下是初步方案：

      文件系统是对装文件的磁盘空间的文件布局、目录树组织的一种描述。有很多种文件系统，它们的空间接口都不一样。即使同一种文件系统，由于在不同的设备上，其空间接口也不一样。空间接口就是指文件系统空间与内存空间连结的方法集合。所以，文件系统类型.设备类型.空间接口.方法i.文件（参数），才能操作到具体的文件。所以，文件系统必须有一个超级块，也就是MFT（卷的根目录）。或简单说，操作一个文件，必须将它对应的树根也打开。MFT超级块有文件系统类型号、设备号、连到每一个文件的路径等等。不同的文件系统安装到APO系统中的一个子目录时，就加装了MFT。这样，其它文件系统也能在APO中使用；这跟unix/linux的VFS类似。

        为了追求速度的极致，APO不得不采取极端设计。APO的数据总线速度是512GBPS；而SATA3接口的固态硬盘的速度只是6GBPS，相对说就太慢了。如果固态硬盘接口和内部总线也采用256位数据总线，即使有存储芯片的限制；做到64GBPS应该不难，随机读取固态硬盘的一行数据速度可以做到256ME/S= 8GB/S。如果所有的文件系统中的文件名哈希值都统一对应映射到APO中的一个相应i节点；也就是说哈希节点就是i节点。APO卷有4G个i节点号，所以，最多有4G个文件或目录。这样，如果我们将所有的目录文件和包含MFT的32个元文件全部放在固态硬盘，需要多大空间？一个i节点是2W，需要4G*2W = 32GB的i节点空间。一个目录项是4E；那需要  4G*4E = 16GE = 512 GB 目录项空间。同或不同文件名的相同哈希值的项是极少的，相同哈希值的列表文件占空间不到64MB；其它元文件占的空间更少。那些小文件（文件内容占行数1到128行）全部集中在一个16GB的空间中，一个 XWJGL文件管理有将近16M个小文件。所以，固态硬盘有1TB的空间就够用了。除了以上的文件，其它文件的内容都是放在普通硬盘的空间中。固态硬盘有连续页、和连续数据块的2种管理模式；APO最大支持4G个数据块的空间（8PB）、32位的块号；连续页管理则需要空间4GY = 8MC = 16TB、32位的页号。

     当用户从控制台，发“列出一个目录内的所有文件”的消息；系统从该目录文件的内容读出一项项目录项时，当然是希望目录项能包含有全部相关的文件属性。而不是，一个一个inode去I/O；磁盘寻道；那会很慢。尽管，只是从2个文件（目录文件、MFT文件）中，读取信息；相对于从多个文件读取要快。但，如果只从一个目录文件读取信息，就不需来回磁盘寻道了。这个差别很大的，比如、目录内的文件数为10M个（1千万个），linux的i节点为128B；磁盘平均寻道时间为10ms，即使不算访问时间；就算1千万个来回寻道时间也要耗时：100K秒 ～= 28小时。如果，只是从一个大文件读取，那就快多了；寻道时间10ms，访问时间：10M * 128B / 160MB/s = 8s。APO是使用固态硬盘保存目录项，并且文件的属性都在目录项里，一个目录项4E；应用程序可以调用系统的戳穿方法（不用阻塞、不经过日志文件服务进程、直达硬件驱动程序），直接读入文件的所有目录项到流容器，速度64M个目录项/S；那么只需0.16s就可全部列出一个目录内的所有10M文件。那么，速度就会比linux快63万倍。

      当要删除一个目录时，如果目录内有10M个文件。那么，linux就需要从2个文件（目录文件、MFT文件）中，来回磁盘寻道了、一个一个inode去I/O读取信息、释放磁盘空间、释放i节点。我不清楚linux的释放时间是多少？但，漫长的过程，加上不会全是一个进程独占；加上进程切换等，估计耗时会翻3倍多、达到100小时以上。APO的目录项中就有文件内容的数据块指针，所以、释放磁盘空间就可在目录文件进行。释放文件中的一段连续数据空间，大约耗时20ns；就算平均一个文件有1.5个连续段，那也就是：30ns*10M = 0.3s，再加上读取目录项的0.16s；不到0.5s就可完成，速度就会比linux快70万倍。APO释放i节点？APO甚至不用删除目录项，只是在该目录文件的父目录文件的对应目录项清0；相应的i节点置空。

      当要按照10级的路径寻找和打开一个文件时，如果每级目录节点下都有1M个目录项；那么，linux从根目录开始一级一级往下寻找；每一级都要一个一个目录项比较，就算使用了文件名字长度及后来增加的文件类型，用轻型比较加快了速度；而不是每次都要比较“长的文件名字”。每次比较，就算0.1us；那也要10*1M*0.1us = 1s的时间，嗯、勉强满足使用要求。当每级目录节点下都有10M个目录项时，那就要晕倒了。我不知道linux为何不用文件名字哈希值来做比较？APO是直接得到i节点的，APO的i节点就是文件名字的哈希值。管你是有n级的路径，APO在ns级就可建立内存的v节点（包含文件的i节点和对应的目录项）。所以，比起linux要快个几十万倍，是很自然的。

     当没有路径时，要遍历整个目录树。咋办？有更好的方法吗？按树状目录查找已经是比不按顺序的查找要好的多了。还有好办法？嗯，B+树。B+树能够使资料保持有序，并拥有均匀的对数处理时间的插入和删除动作。B树的元素通常会自底向上插入，有别于多数自顶向下插入的二叉树。6级的B+树，可能7次i/o就能定位目标文件。当没有路径时，用文件名字的哈希值搜B+树，几次i/o就可定位到目标文件i节点号；这是不错。但B+树的索引节点指针需额外占用磁盘空间，大约一个文件需6W，如果有2G文件时就可观了，要多用12GW = 48GB的硬盘空间。B+树只适合小量文件的场合。B+树是自我分裂的，小量文件时，额外占用磁盘空间不大；不过每次多花点时间吧。那也是要花时间和多占空间啊，真是奇能淫技啊！改进了一些，过于复杂还是属于小聪明；相比APO的方法还是差远了。说真的、不是我想吹牛b；目前也不知道APO这种方法是否有缺陷。

      当我们查找名字第一位字符是x的所有文件时，哈希值没用了，B+树没用了，unix/linux技穷了，只能遍历整个目录树；磁头频繁移动，慢如乌龟了！APO也是只能是遍所有的目录文件。但APO的目录文件都是放在固态硬盘，无需磁盘寻道；而APO的多功能硬件模块可以在10ns比较4K个目录项；就算总共有1G个目录项，读入、装配4K个目录项需要耗时4K/64M/s = 64us，那么，总耗时16s。你可以试一下，WINDOWS、LINUX如果遍历1G个目录项需耗时多少？就算它们能一分钟扫描1万个目录项并作比较，也要耗时1G/0.01M/60s = 1700小时。

      那个EXT4文件系统，不过是预留一些就近i节点给目录文件，让同一个目录下的少部分文件i节点能靠在一起；稍微减少一些I/O操作。那些“叫兽”就鬼叫，搞得我都脸红。

      APO文件系统就是一个卷描述文档，提供了磁盘压缩、数据加密、磁盘配额(用户可以通过磁盘配额监视和限制磁盘空间的使用)、动态挂载其它文件系统、动态磁盘管理等功能，总共可有256T个64KE的块，所以APO文件系统最大支持到256T*64KE=16EE=512EB的磁盘空间。有最大64K - 256个卷，卷中的每一个数据块64KE,都有一个特定的序号，这个序号就叫做逻辑块号LJID，逻辑块号0指向卷中的第一个块，每个卷总共有4G块。最大支持256TE的磁盘空间。卷、或文件系统根目录可能连结在不同的设备上，所以打开一个文件，它对应的文件系统根目录也要打开。存放在块中的简单的字符排列数据称为流；每一个流都由起始块号和尺寸来描述。节点描述符也称为元数据，按节点ID从0开始的顺序的元数据流构成元数据文件MFT。最大文件2G*64KE = 128TE = 4PB。16位既是2字节2B或一个字符Z，2个字符为1字W；一行E为16个字符16Z或8个字8W，一个数据块是512KW或64KE或2MB或512页；一页Y是128E或4KB或2KZ/1KW，一个单元C是64K个数据块；一个卷J是64K个单元。

      流stream就是指很大的数据流、甚至无限的数据流；通常的文件数据、我们就看作是一个数据流。因为内存空间有限，不可能完全装入一个大的数据流