如何估计文件系统中的查找速度

Question

假设使用ext4文件系统，1TB SSD上有一个大文件（以500MB /秒的速度读写）。此文件的大小接近1TB。如何估计fseek（）到文件中间的速度。它需要几秒或几毫秒？感谢。

Answer 1

为了估计fseek的延迟，我们应该将其分为两部分：软件工作和硬件寻道时间延迟。软件工作是ext4文件系统的实现（FS，在Linux中这是内核的VFS子系统），它将生成几个＆＃34; random＆＃34;请求（I / O操作）到硬件块存储设备。硬件将使用一些时间来处理每个随机请求。

经典UNIX文件系统（UFS / FFS）和linux文件系统，在它们之后设计，使用超级块来描述磁盘上的fs，将文件存储为inode s（已知位置有inode数组）和存储以固定大小的块文件数据（在Linux中最多4KB）。要从文件名OS中查找inode，必须读取超级块，查找路径中的每个目录，从目录中读取数据以查找该文件具有的inode编号（ls -i将显示当前目录的inode）。然后，使用来自超级块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具有指向具有文件块列表的一个块的指针（间接寻址的块）。如果file较大，则使用inode中的下一个指针来描述＆＃34;双重间接块＆＃34;。它指向枚举其他块的块，每个块包含指向具有实际数据的块的指针。有时需要三重间接块指针。这些树相当有效，在每个级别都有~512度（4KB块，每个指针8个字节）。因此，要从文件中间访问数据，ext2 / 3/4可能会生成多达4-5个低级I / O请求（超级块缓存在RAM中，inode也可能被缓存）。这些请求不会在地址中产生，因此它们几乎是随机寻找块设备。

linux FS（ext4，XFS）的现代变体对巨大的文件存储进行了优化，称为范围（https://en.wikipedia.org/wiki/Extent_(file_systems)）。范围允许FS将文件放置描述为块列表，而不是文件片段/指针对的数组（start_block，number_of_consequent_blocks）。每个片段可能来自MB的一部分，最大为128 MB。 4个第一个扩展区存储在inode中，更多扩展区再次存储为树状结构。因此，对于扩展区，您可能需要2-4个随机I / O操作来访问文件的中间位置。

硬盘驱动器对随机请求的访问时间很慢，因为它们应该物理地将标头移动到正确的圆形轨道（并且在轨道上精确定位标头;这需要旋转的某些部分，如1/8或1/16要完成）然后等待最多1次旋转（旋转）的磁盘（盘片）以获得所请求的部分轨道。 HDD的典型旋转速度为5400和7200 rpm（revolutions per minute，90 rps和120 rps）或高速企业HDD - 10000 rpm和15 rpm（160 rps和250 rps）。因此，从磁盘随机位置获取数据所需的平均时间约为0.7-1转，对于典型的7200转/分钟（120rps），它约为1/120秒= 8毫秒（毫秒）= 0.008秒。获取每个随机请求的数据需要8ms，并且在您的情况下最多有4-5个随机请求，因此对于 HDD ，您可能会期望接近40 ms 寻找档案。 （首先寻求将花费更多，下一次搜索可能会更便宜，因为块指针树的某些部分被OS缓存;寻找几个下一个块非常便宜，因为linux可以在请求第一次搜索后读取它们。）

SSD没有旋转或移动部件，SSD上的任何请求都以相同的方式处理。 SSD控制器使用自己的转换表将请求的块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 ms;在2014年;延迟的某些部分是慢速SATA / SCSI仿真; NVMe SSD可能更快，因为他们使用更简单的软件堆栈）。根据我们的4-5个请求，我们可以将SSD 上的fseek 估计为几毫秒，例如最多 1 - 1.5 ms 或有时更长。

您可以使用fseek检查strace -T ./your_fseek_program所需的时间。它将报告执行每个系统调用所需的时间。但要获得真正的延迟，您不仅应该检查寻找时间，还要检查下一个read系统调用的时间。在每次运行此测试之前，您可能希望使用来自根（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来估算搜索潜伏期。