フォルダの閲覧中に、ncduファイルの見かけのサイズが実際のディスク使用量よりはるかに大きい場合があることがわかりました。例を見てncduから、aディスク使用量表示と明確な表示を切り替えて、追加の詳細i表示を実行します。
これは、データの一部だけが「高速」階層に残り、残りの部分がより遅い場所（AWS S3など）に残る自動化されたプロセスによって引き起こされる可能性があると言われました。どうやって確認しますか？
〜のように提案渡すクリスタンhexdump、以下はそのファイルで実行された部分出力です。
これは、ファイルが稀でないことを示すようです。
〜のように提案渡すアルトゥーンS.タシュキノフ、ファイルシステムは光沢（確認に使用sudo df -T）。
ベストアンサー1
これは一般的な（しかし明確ではない）動作です。Lustreなどの階層型ストレージシステム。ncdu他の希少測定ツールはしばしば与えられた値に依存する。st_blocksに答えるstat呼ぶ。記録中のコピーではないファイルシステムで明らかな動作は、私たちが期待するものと同じです。各ファイルは、ディスクに含まれるゼロ以外のデータの正確な量を最小限に抑えますst_blocks。ファイルに0が保存されました。 Lustreは、st_blocksファイルに保存されているデータの総量ではなく、フロントエンドシステムで使用されるストレージを表します。
唯一の小さな例外があります。 「公開された」ファイル（コンテンツがフロントエンドストアから完全に削除された）は、ゼロ以外の512バイトを占めるようにマークされています。これが達成されるツールの問題に対する解決策として、たとえば次のようになります。tarこれによりst_blocks、ゼロのあるファイルの読み取りが完全にスキップされ、Lustreベースのファイルシステムでデータが失われます（バックアップシナリオで一般的なスパースファイル検出を使用して公開されたファイルをアーカイブすると、データはまったく保存されません）。ファイルが512バイトを占めるとマークされている場合、ツールはそのファイルを読み取る必要があります（またはfiemapioctlなど）含まれている内容を正確に確認するためにLustreでこれを行うと、階層に格納されている場所からファイルデータを取得できます。
大容量ファイルの場合、ファイル全体をフロントエンドストレージに復元することはまれです。