我如何找出文件在磁盘上的物理位置（块编号）？

10

我知道这是一个晦涩的问题。我正在尝试对Linux机器上的某些磁盘进行性能测试。在同一磁盘上运行相同的测试时，结果不一致。我知道磁盘具有不同的性能，具体取决于正在访问磁盘的哪一部分。特别地，由于接近恒定的数据密度和恒定的旋转速度，对磁盘外部的读写比对磁盘内部的读写具有更高的吞吐量。

我想看看我的不一致是否可以归因于这种几何形状导致的吞吐量差异。是否可以使用现有工具找出文件在磁盘上的放置位置？

如果没有，我想我可以写一些东西来直接查找，读取和写入设备文件本身，从而绕过（并销毁）文件系统，但是我希望避免这种情况。我目前在3.0内核（Arch Linux，如果有关系）上使用ext4，但是我也对其他文件系统的技术感兴趣。

— 里克·科希
source

1

谁说文件放在一个地方？如果他们变得支离破碎（他们通常这样做），他们可能会全部结束。

— Sirex

绝对。但他们仍然在某处 :-)在我的特定情况下，将文件写入到新创建的文件系统，他们很可能是（大部分）不分段。

— 瑞克·科希

你做不到最好的选择是文件的LBA块号，它们不一定与指定的物理位置相对应（至少不是以您可以确定的方式，因为驱动器不会发布此映射）。也有其他事情，例如，块3-5可能被连续编号，但是可能已将4块重新分配到驱动器上的一个完全不同的位置，因为4处的原始扇区受到了物理损坏，等等。您无法获取该信息除非驱动器制造商愿意为您提供详细的地址规格，否则您将一直在寻找。

— 2014年

7

您可以debugfs为此：

debugfs -R "stat ~/myfile" /dev/hda1

相应地更改硬盘驱动器/分区驱动器，并确保已卸下驱动器。您将获得包含所有使用的块的列表：

BLOCKS:
(0):1643532
TOTAL: 1

— 巴特·德沃斯
source

1

完美，谢谢。不过，我不确定为什么要说要确保已卸载驱动器。根据手册页，debugfs默认情况下以只读模式打开，因此即使在活动文件系统上，此命令也应完全安全。当然，如果此时正在主动更改查询的文件，它可能会提供可疑的结果，但是不会导致其他问题。我错过了什么吗？

— 瑞克·科希

不，你是对的。这更多的是“最佳实践”，而必须的。如果您正在活动的文件系统，这样做，文件可能会改变等等

— 巴特德沃思

1

LBA块号不会告诉您文件在磁盘上的物理位置。由于现代驱动器的物理几何结构的复杂性，幕后扇区的重新分配等原因，如今通常无法将LBA转换为物理位置。通常来说，对于基于磁盘的较低LBA的介质来说，通常是一个安全的选择朝向驱动器的外部，但这仅是因为这种布局在CHS寻址时代已成为过去的典型做法。现代驱动器甚至不再发布实际的CHS几何图形，因为它们无法发布。

— 詹森·C

胖子系统如何？

— dashesy

10

您可以使用FIBMAP IOCTL，例证这里，或使用hdparm的：

/ $ sudo /sbin/hdparm --fibmap /etc/X11/xorg.conf

/etc/X11/xorg.conf:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    1579088    1579095          8

— 弗朗索瓦·G
source

不幸的是，stat所输出的信息都不是我需要的信息。以字节和块为单位的大小，索引节点号，权限...这些都不能反映哪些块包含文件的数据。例如，我的测试文件（大小都相同）都显示完全相同的数据，除了inode数量和访问/修改时间。

— 里克·科希

是的，您说得对，对不起，我没有正确阅读。我将答案更改为stg更合适。

— 弗朗索瓦·G

hdparm确实确实满足了我的需求，并且格式比debugfs更具可读性。不过，我必须去找到它，因为默认情况下未安装（在Arch Linux上）。debugfs是e2fsprogs（为我们提供mkfs和fsck的相同软件包）的一部分，因此默认情况下已安装。

— 里克·科希

LBA不会告诉您文件在驱动器上的物理位置。无法获得有关LBA实际物理映射的信息。

— 詹森·C

我很胖：HDIO_GETGEO failed: Inappropriate ioctl for device

— dashesy

5

该线程可能使您对ext4文件放置算法有一些了解。

debugfs有一个bmap功能，似乎可以提供您想要的数据。您应该能够为它提供文件的连续块并获得物理块号。

— PawełBrodacki
source

1

感谢您指向有关ext4文件放置的线程的指针。那很启发。:-)

— Rick Koshi

LBA不会告诉您文件在驱动器上的物理位置。无法获得有关LBA实际物理映射的信息。

— 詹森·C

2

这个问题已经很老了，但是还有另一个答案可能对那些在Google上找到这个答案的人有用：（filefrag在Debian中，它在package中e2fsprogs）。

# filefrag -eX /usr/bin/aptitude
Filesystem type is: ef53
File size of /usr/bin/aptitude is 4261400 (1041 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     1fa:    15bd805..   15bd9ff:    1fb:            
   1:      1fb..     3f2:    15c6608..   15c67ff:    1f8:    15bda00:
   2:      3f3..     410:    15c8680..   15c869d:     1e:    15c6800: last,eof
/usr/bin/aptitude: 3 extents found

它的优点是它也适用于其他文件系统（我将其用于UDF），此处所述的其他工具似乎不支持该文件系统。

输出中显示的偏移量应为第二行中写入的块大小的倍数（此处为4096）。注意逻辑偏移量可能不是连续的，因为文件中可能有孔（当文件系统支持时）。

— 乔凡尼·马塞拉尼（Giovanni Mascellani）
source