ファイルシステムのルート用に予約されたスペース-なぜですか？

デフォルトでは、新しく作成されたファイルシステムは、ルートに割り当てられたスペースの5％で作成されることを理解しています。また、定義済みのスペースを次の方法で変更できることも知っています。

tune2fs -m 1 /dev/sdXY

しかし、私が興味を持っているのは、この予約済みスペースの実際の目的です。状況によっては5％以上のスペースに値する実用的な目的に役立ちますか？

私がこの質問に出くわした理由は、最近1TBのファイルストアを構築したため、df -hによって容量の5％が失われた理由を十分に理解できなかったためです。

重要なルートプロセス（および可能なレスキューアクション）のスペースを節約することが1つの理由です。

しかし、別のものがあります。Ext3はファイルシステムの断片化を回避するのに非常に優れていますが、約95％を超えると、その動作は崖から落ち、ファイルシステムのパフォーマンスが突然混乱します。したがって、5％を予約したままにすると、これに対するバッファーが得られます。

Linuxファイルシステム開発者/グルのTheodore Ts'oが説明したように、Ext4はこれで優れているはずです。

予約済みブロック数をゼロに設定すると、ファイルシステムがほぼ満杯の状態（たとえば95％以上）で長時間（多くのファイルの作成と削除を）実行する場合を除いて、パフォーマンスに大きな影響はありません。その時点で、断片化の問題が発生します。Ext4のマルチブロックアロケーターは、連続するブロックを見つけるのがはるかに難しくなるため、フラグメンテーション耐性がはるかに高くなります。したがって、他のext4機能を有効にしない場合でも、ファイルシステムの前にext4完全にいっぱいになります。

ファイルがあまり頻繁に変更されない長期的なアーカイブ（つまり、巨大なmp3またはビデオストア）にファイルシステムを使用しているだけであれば、明らかに問題にはなりません。

たとえば、sshを介して他のユーザーにシステムへのログオンを許可する場合、これらの5％ブロックを予約しておくと、外部ユーザーがディスクをいっぱいにできなくなります。他のユーザーにシステムへのログインを許可しない場合でも、予約済みブロックにより、rootとして実行されていないプログラムがディスクをいっぱいにしないようにします。

ユーザーを予約したブロックと、rootとして実行するのではなく特定のユーザーとして実行しているサービスは、filesystsemを埋めることができず、前述のファイルシステムに書き込む必要がある他のものを破壊する可能性があります-ただし、rootとして実行しているサービスでも完全に実行できますもちろんいっぱい。

また、ユーザーがディスクがいっぱいであると不平を言ったり、ファイルシステムがいっぱいになったためにサービスが失敗し始めたりしたときに、作業するスペースを確保します。たとえば、削除する前にいくつかのファイルをzip / gz / 7zipアーカイブにアーカイブできます（ただし、ファイルシステムが完全にいっぱいの場合、代わりにアーカイブファイルを作成できる他のファイルシステムがある可能性があります）。

5％は、ディスクがはるかに小さかった頃（数百ギガバイトではなく数十メガバイト）から、長い間デフォルトでした。そのため、5％はそれほど多くありませんでした。幸いなことに、あなたが言うように、それを簡単に小さなパーセンテージに調整するか、の代わりにtune2fsの-rオプションを使用する場合、特定のブロック数に設定することができます-m。どちらの場合も、あなたは完全にオフの予約を有効にする0のパラメータを与えることができます-私はこれをしないだろう/、/tmp、/varなどがありますが、唯一のユーザーのストレージ（たとえばグローバルファイル-として動作するファイルシステムのためにお勧めします共有）、または固定サイズのファイル（固定サイズのVMなど）を保持するだけで、新しいファイルを作成したときにのみ成長します。

デフォルトの5％は、システムパーティション用です。たとえば、ディスク容量がいっぱいになった場合でも、システムログ（/var/log）およびルートのメールボックス（/var/mail/root）は重要な情報を受信できます。以下のため/homeか、一般的なデータ・ストレージ・パーティション、ルートのいずれかのスペースを残しておく必要はありません。特別なニーズの場合、緊急スペースを取得するユーザーを変更できます（tune2fs -u 1234）。

ext [234]ファイルシステムがいっぱいになることを許可しない別の理由があります。これはフラグメンテーションです。