☰

ファイルを読み取るためにhexdumpを使用すると、findのスパース値（％S）が変更されるのはなぜですか？

tag-icon • tag-icon find sparse-files lustre
ファイルを読み取るためにhexdumpを使用すると、findのスパース値（％S）が変更されるのはなぜですか？

私はLustreファイルシステムを使用しています。%Sファイルのfind（）の希少値を見た後、を使用してそのファイルを印刷してからfindの希少hexdump値を見直すと、時々find（%S）の希少値が変わることがわかりました。なぜ変わったのですか？

%Sまれな値を探す（）コマンドを使用してファイルを表示するmyvideo.mp4：

find myvideo.mp4 -printf "%S"

myvideo.mp4ファイルを読み取るには、次のコマンドを使用しますhexdump。

hexdump myvideo.mp4

複数のファイルでこの動作が見つかりました。検索（ ）の希少値の変更例%S：

  • 0.000135559到着0.631297
  • 0.00466808到着0.228736

readを使用するとファイルが部分的にローカルにキャッシュされるためですかhexdump？私はこの変更が特定的ではないことを知りました。たとえば、（そしておそらくファイルを読む他のプログラムでも）hexdump同じことが起こります：nano

dernoncourt@server:/videos$ find myvideo.mp4 -printf "%S"
0.00302331
dernoncourt@server:/videos$ nano myvideo.mp4 
dernoncourt@server:/videos$ find myvideo.mp4 -printf "%S"
0.486752

ベストアンサー1

（この回答のすべての情報は、 スティーブン・チャジェラス~のコメント。ありがとうございます！ )

~から検索マニュアルページ（形式は私のものです）：

%S:ファイルの希少性です。その計算式は（BLOCKSIZE*st_blocks / st_size）です。特定の長さの通常のファイルに対して取得できる正確な値は、システムによって異なります。しかし、スパースファイルは通常1.0未満の値を持ち、間接ブロックを使用するファイルは1.0より大きい値を持つことができます。使用される値はBLOCKSIZEシステムによって異なりますが、通常512バイトです。ファイルサイズが0の場合、印刷された値は未定義です。サポートされていないシステムでは、st_blocksファイルのスパースは1.0と見なされます。

気づく:

  • BLOCKSIZE*st_blocksディスク使用量に応じて、
  • st_size見かけのサイズに対応します。

したがって%S== BLOCKSIZE*st_blocks / st_size。diskusage/apparentsize

さらに、回答ファイルの見かけのサイズが時々実際のディスク使用量よりはるかに大きい理由を解決します。Lustreなどの階層型ストレージシステムまったくリーンではないかもしれませんが。大容量ファイルをフロントエンドストレージに完全に復元することは異例であることも述べた。

hexdumpなどのプログラムを使用してファイルを読み込むと、フロントエンドストレージに部分的に復元される場合があるため、nanoこのst_blocks値が増加して減少するため、%S (=BLOCKSIZE*st_blocks / st_size)（）で報告するファイルの希少性が減少するという意味です。find%S

Lustreファイルシステムのファイルがリーンかどうかを知ることは役に立たないので、find myvideo.mp4 -printf "%S"次のコマンドを使用できます。解決策渡すフロストスーツファイルが希薄であることを確認してください。

file = "myvideo.mp4"
if [ "$((`stat -c '%b*%B-%s' -- "$file"`))" -lt 0 ]
then
    echo "$file" is sparse
else
    echo "$file" is not sparse
fi

このソリューションには、次の制限事項がいくつかあります。コメントエリア。

そして光沢にも注意してください確かに現在SEEK_HOLE/SEEK_DATA、インターフェースは直接サポートされているため使用できません。このソリューションを使用してくださいLustreのファイルがリーンかどうか理解しています。

おすすめ記事