ファイルが物理的にディスク上のどこにあるか（ブロック番号）を確認するにはどうすればよいですか？

10

これはあいまいな質問だと思います。Linuxボックスでいくつかのディスクのパフォーマンステストを実行しようとしています。同じディスクで同じテストを実行すると、一貫性のない結果が得られます。ディスクのどの部分にアクセスするかによって、ディスクのパフォーマンスが異なることは知っています。特に、データ密度がほぼ一定で回転速度が一定であるため、ディスクの外側への読み取りと書き込みは、ディスクの内側への読み取りと書き込みよりもスループットがはるかに高くなります。

私の不整合が、このジオメトリに起因するスループットの変動に起因する可能性があるかどうかを確認したいと思います。既存のツールを使用して、ディスク上のファイルが配置されている場所を見つけることは可能ですか？

そうでない場合は、ファイルシステムをバイパス（および破棄）して、デバイスファイル自体に直接シーク、読み取り、および書き込みを行う何かを書き込むことができると思いますが、それを回避したいと考えています。現在、3.0カーネル（Arch Linux、重要な場合）でext4を使用していますが、他のファイルシステムの手法にも興味があります。

— リック・コシ
ソース

1

ファイルが1か所にあると誰が言うのですか？断片化された場合（通常は断片化されます）、最終的にはすべてが終了する可能性があります。

— Sirex

もちろんです。しかし、それらはまだどこかにあります :-)そして、私の特定のケースでは、新しく作成されたファイルシステムにファイルを書き込む場合、それらは（ほとんど）断片化されていない可能性が非常に高いです。

— Rick Koshi

これはできません。あなたが得ることができる最高のものは、必ずしも指定された物理的な場所に必ずしも対応しないファイルのLBAブロック番号です（少なくともドライブがこのマッピングを公開しないので、あなたが決定できる方法ではありません）。他にもいくつかあります。たとえば、ブロック3〜5は連続して番号が付けられている可能性がありますが、4の元のセクターが物理的に破損しているなどの理由で、4がドライブ上の完全に異なる場所に再割り当てされている可能性があります。情報を取得できません。ドライブの製造元が詳細なアドレス仕様を提供する用意がある場合を除いて、あなたは探しています。

— Jason C

7

あなたはdebugfsこれに使うことができます：

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

ハード/パーティションドライブを適宜変更し、ドライブがマウント解除されていることを確認します。使用されているすべてのブロックのリストが表示されます。

BLOCKS:
(0):1643532
TOTAL: 1

— バート・デ・ヴォス
ソース

1

これは完璧です、ありがとう。ドライブがアンマウントされていることを確認するように言った理由がわかりません。マニュアルページによると、デフォルトではdebugfsは読み取り専用モードで開くため、このコマンドはアクティブなファイルシステムでも完全に安全です。もちろん、クエリされたファイルがその時点でアクティブに変更されている場合、疑わしい結果が得られる可能性がありますが、他の問題は発生しません。私は何かを見逃しましたか？

— Rick Koshi

いいえ、そうです。それは「ベストプラクティス」よりも必須です。あなたがアクティブなファイルシステム上でそれをやっている場合は、ファイル等を変更することができ

— バート・デ・ヴォス

1

LBAブロック番号は、ファイルがディスク上の物理的にどこにあるかを示していません。物理的な場所へのLBAから、これらの日の変換は一般的に、それはだいえば、による最近のドライブの物理的な形状の複雑さのために、一般的に舞台裏セクターの再配分などはできません通常は安全な賭けそのディスクベースのメディアには、LBAのを下げるためにはドライブの外側に向かっていますが、それは、そのレイアウトが過去に典型的であり、CHSアドレッシング時代に戻ったからです。最新のドライブは、実際のCHSジオメトリを公開することさえできません。

— Jason C

ファットファイシステムはどうですか？

— ダッシュ1995

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
ソース

残念ながら、statが出力するものは何も必要な情報ではありません。バイトとブロックのサイズ、iノード番号、権限...これらのどれも、ファイルのデータを含むブロックを反映していません。例として、私のテストファイル（すべて同じサイズ）は、inode番号とアクセス/変更時間を除いて、まったく同じデータを示します。

— Rick Koshi

はい、あなたは正しいです、申し訳ありません、私は正しく読みませんでした。答えをstgに変更しました。

— Francois G

hdparmは確かに私に必要なものを提供し、debugfsよりやや読みやすい形式です。ただし、デフォルトではインストールされていないので（Arch Linuxに）インストールされていないので、見つけに行かなければなりませんでした。debugfsはe2fsprogs（mkfsとfsckを提供する同じパッケージ）の一部であるため、デフォルトでインストールされます。

— Rick Koshi

LBAは、ファイルがドライブ上の物理的にどこにあるかを通知しません。LBAの実際の物理マッピングに関する情報を取得することはできません。

— Jason C

私はこれを太っています：HDIO_GETGEO failed: Inappropriate ioctl for device

— ダッシュ1995

5

このスレッドは、ext4ファイル配置アルゴリズムについての洞察を提供します。

debugfsbmapあなたが望むデータを与えるように見える関数を持っています。ファイルの連続したブロックを与え、物理ブロック番号を取得できるはずです。

— パヴェイ・ブロダッキ
ソース

1

ext4ファイルの配置に関するスレッドへのポインタをありがとう。それは啓発的でした。:-)

— リック・コシ

LBAは、ファイルがドライブ上の物理的にどこにあるかを通知しません。LBAの実際の物理マッピングに関する情報を取得することはできません。

— Jason C

2

質問はかなり古いですが、Googleでこれを見つけた人に役立つ可能性のある別の回答がありますfilefrag（Debianでは、パッケージ内にあります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で使用しました）でも機能するという利点があります。

出力に表示されるオフセットは、2行目に記述されているブロックサイズ（ここでは4096）の倍数になることを意味しています。ファイルに穴がある場合があるため（ファイルシステムでサポートされている場合）、論理オフセットが連続していない場合があることに注意してください。

— ジョバンニ・マスチェラーニ
ソース