linux - 如何估算文件系统中的查找速度

Question

假设使用ext4文件系统的1TB SSD上有一个大文件(读写速度为500MB/秒)。该文件的大小接近1TB。如何估计fseek()到文件中间的速度。需要几秒钟还是几毫秒？谢谢。

Answer 1

要估计fseek的延迟，我们应该将其分为两部分:软件工作和硬件寻道时间延迟。软件工作是ext4文件系统(FS，在Linux中是内核的VFS子系统)的实现，它将对硬件块存储设备生成多个“随机”请求(I/O操作)。硬件将花费一些时间来处理每个随机请求。
在它们之后设计的经典UNIX文件系统(UFS/FFS)和linux文件系统，使用 super 块来描述fs在磁盘上的布局，将文件存储为inode s(在已知位置有inode的数组)，并将文件数据存储在固定大小的块中(在Linux中最大为4KB)。要从文件名中查找 inode ，操作系统必须读取 super 块，查找路径中的每个目录，从目录中读取数据，以查找文件具有的 inode 号(ls -i将向您显示当前目录的 inode )。然后，使用来自 super 块OS的数据可以计算出inode的存储位置并读取inode。
Inode包含文件数据块的列表，通常为树状结构，请检查https://en.wikipedia.org/wiki/Inode_pointer_structure或http://e2fsprogs.sourceforge.net/ext2intro.html

文件的第一部分，将几十KB存储在块中，直接在inode中列出(直接块； ext2/3/4中为12)。对于较大的文件，inode指向带有文件块列表(间接寻址的块)的一个块的指针。如果文件较大，则使用inode中的下一个指针来描述“双间接块”。它指向枚举其他块的块，每个块都包含指向具有实际数据的块的指针。有时需要三重间接块指针。这些树相当有效，在每个级别上都有〜512的程度(4KB块，每个指针8个字节)。因此，要从文件中间访问数据，ext2/3/4可能会生成多达4-5个低级I/O请求( super 块存储在RAM中，inode也可以存储)。这些请求不是地址中的结果，因此它们几乎是对块设备的随机查找。
linux FS的现代变体(ext4，XFS)对称为扩展区(https://en.wikipedia.org/wiki/Extent_(file_systems))的巨大文件存储进行了优化。范围允许FS将文件放置描述为不是文件列表，而是文件片段/指针对数组(start_block，number_of_consequent_blocks)。每个片段可能从MB的一部分到128 MB。第四个扩展区存储在inode内，更多扩展区再次存储为树状结构。因此，在某种程度上，您可能需要2-4次随机I/O操作才能访问文件的中间部分。
HDD对于随机请求的访问时间很慢，因为它们应物理移动 header 以校正圆形轨道(并将 header 准确地定位在轨道上；这需要旋转某些部分，例如要完成1/8或1/16)，然后等待最多旋转(旋转)磁盘(片)1次即可获得轨道的请求部分。 HDD的典型转速为5400和7200 rpm(revolutions per minute，90 rps和120 rps)，或者对于高速企业HDD来说，转速为10000 rpm和15000 rpm(160 rps和250 rps)。因此，从磁盘的随机位置获取数据所需的平均时间约为0.7-1圈，对于典型的7200 rpm hdd(120rps)，约为1/120秒= 8 ms(毫秒)= 0.008 s。每个随机请求都需要8ms的时间来获取数据，根据您的情况，最多有4-5个随机请求，因此使用 HDD 时，您可能希望在40 ms 附近寻找的时间来查找文件。 (第一次寻道将花费更多，由于操作系统将块指针树的某些部分缓存起来，因此下次寻道可能会更便宜；对几个接下来的块的寻道非常便宜，因为linux可以在请求第一次寻道之后立即读取它们)。
SSD没有旋转或运动部件，并且对SSD的任何请求都以相同的方式处理。 SSD Controller 使用自己的转换表将请求的块ID解析为内部nand芯片+块ID，然后读取实际数据。从NAND读取数据将检查纠错码，有时需要多次内部重读才能正确读取该块。在便宜的NAND类型中，读取速度较慢-在每个单元中存储3位数据的TLC-8级；在MLC中更快-具有4级的2位数据;在不存在的SLC SSD中，只有1位和2级，非常快。磨损的SSD或固件中存在错误(错误的电池电荷降级模型)的SSD读取速度也较慢。
SSD中此类随机访问的速度非常快，通常将其声明为SSD规范，例如50000-100000 IOPS(I/O operations per second，通常为4KB)。高IOPS计数可能会声明用于更深的队列，因此SSD(带有QD1)的实际平均平均随机读取延迟是每个请求200-300 microseconds(0.2-0.3毫秒； 2014年；延迟的一部分是较慢的SATA/SCSI仿真； NVMe SSD可能更快，因为他们使用了更简单的软件堆栈)。通过我们的4-5个请求，我们可以估计SSD的上的fseek 为几毫秒，例如，最长 1-1.5 ms 或有时更长。
您可以使用fseek检查strace -T ./your_fseek_program所需的时间。它将报告执行每个系统调用所需的时间。但是要获得实际的延迟，您不仅应检查查找时间，还应检查下一个read系统调用的时间。在每次运行此测试之前，您可能需要使用root(https://unix.stackexchange.com/questions/17936/setting-proc-sys-vm-drop-caches-to-clear-cache)中的echo 3 > /proc/sys/vm/drop_caches命令刷新内核缓存。
您也可以尝试使用某些I/O基准测试(例如iozone，iometer或fio)来估计寻道延迟。