☰

ファイルのサイズ（Nemoによる）はありますが、ディスク容量（RAM）を占有しない方法は何ですか？

tag-icon • tag-icon linux filesystems
ファイルのサイズ（Nemoによる）はありますが、ディスク容量（RAM）を占有しない方法は何ですか？

今日、いくつかのファイルをダウンロードしました。 AFAIKアプリケーションは、最初からファイル全体のスペースを予約します。 1 番目と 2 番目のファイルの場合、ダウンロードが開始された後に使用可能な RAM が減少するのがわかりましたが、3 番目のファイルの場合は (メッセージあたり) スペースが不足し、一部のファイルを削除してダウンロードを開始しました。しかし、驚くべきことに、freeまだ多くの空き容量が表示されます。アプリケーションが実行するスペースの一部だけを予約している可能性があると考えてファイルサイズを確認しましたが、そうではなく、Nemoが示すように、ファイルサイズは数GBでした。意図したよりも誤って削除した方が多いかもしれないと思っていましたが、ダウンロードしてみると空きfreeメモリがほとんどないことがわかりました。ファイルシステムはかなり大きいがスペースを占有しないオブジェクト（ファイル）をどのように報告できますか？

システムはUbuntu liveUSBに基づいており、あなたが言ったfindmntようにRAMで起動するので、起動スクリプトについてはよくわからないので（そして質問にどのタグが適用されるのかわからないので、呼び出すことを躊躇します）、原因を特定する必要がある場合は純粋なtmpfsドライブの問題を再現してみることができます。ああ、私の質問は、さまざまなLinuxユーティリティの情報がクラッシュした場合、どのようにこれを信頼できますか？/cowtmpfs

答え1

ファイルの見かけのサイズは、ディスク上で実際に占めるスペースと必ずしも同じではありません。

$ truncate -s 10P hugefile
$ ls -l hugefile
-rw-rw-r--. 1 skitt skitt 11258999068426240 Jan  7 11:49 hugefile

実際には10PiBディスクはありませんが、幸いにもhugefile10PiBを占めません。

$ stat hugefile
  File: hugefile
  Size: 11258999068426240   Blocks: 0          IO Block: 4096   regular file
Device: fd02h/64770d    Inode: 182589989   Links: 1
Access: (0664/-rw-rw-r--)  Uid: (26561/   skitt)   Gid: (26561/   skitt)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2022-01-07 11:49:26.653101365 +0100
Modify: 2022-01-07 11:49:34.631215761 +0100
Change: 2022-01-07 11:49:34.631215761 +0100
 Birth: 2022-01-07 11:49:26.653101365 +0100

ここで重要なフィールドはブロック数0です。

これらのファイルはスパースファイルと呼ばれます。

これは、ファイルの最終サイズが事前に知られているときに機能するダウンロードツールの数です。ファイルの見かけのサイズが常に最終的な「実際の」サイズと同じであるように、ファイルの合計サイズを指定してから書き込みを行います。ファイルを受信すると、ファイルの内容を確認し、徐々にディスク容量を割り当てます。これがあなたが見るものです。

関連情報