Linuxでext-filesystemsが使用するスペースを少なくする方法はありますか?


49

Linuxシステムで使用する外部および内部HDDがたくさんあります。私はLinuxシステムしか持っていないので、Linuxファイルシステムを使用するのは理にかなっているでしょうか?しかし、私は現在どこでもNTFSを使用しています。これは、HDDの中で最も使用可能なスペースを提供するためです。

ただし、主に許可と互換性のために、Linuxファイルシステムに切り替えたいと思います(たとえば、LUKSで暗号化されたNTFSパーティションをLinuxでサイズ変更できず、Windowsでchkdskを指示し続けます)。

しかし、それらのHDDをフォーマットしたとき、さまざまなファイルシステムを試し、すべてのLinuxファイルシステムを試しました。ext2でさえ、ジャーナリングがない限り、それ自体に多くのスペースを使用しました。正確な値は思い出せませんが、NTFSが2TB HDDでさらに多くを獲得したのは100GBを超えていました。

だから私の質問は次のとおりです:ext-filesystemsが自分自身のためにより少ないスペースを使用するようにする方法はありますか?または、別のファイルシステムがありますか(ext2、ext3、ext4、NTFS、vfatを試しました-NTFSが提供する使用可能なスペースに近いものはありませんでした)、完全なLinuxサポートと優れた使用可能なスペースがありますか?

ファイルシステム(特にジャーナリングを持たないext2)がNTFSよりもはるかに多くのスペースを使用する方法と理由について聞きたいのですが、他にどこに問い合わせればよいかわかりません。可能であれば、ジャーナリングなしでext4を使用する方法と、これだけのスペースを使用する他の方法をお勧めします。



4
私は持っていて、余分なスペースを使い果たすものを説明しましたが、NTFSとextの違いはreiserfsとextの違いよりもはるかに大きく、小さくする方法があるのではないかと思っています。たとえば、1TBのHDDでは、NTFSで989GBを使用できます。ext4は約909GBを提供します。
紙吹雪

けっこうだ。まともな質問と答えも啓発的です。
JakeGould

3
使用可能なスペースを実際にどのように測定しますか?これは重要です。たとえば、リンクされた質問
-eMBee

2
ext3やext4などのファイルシステムでのジャーナリングは良いことです。USBの場合、外部ドライブの電源を失ったり、偶然にプラグを抜いたりするのは非常に簡単です。それが発生した場合、バックアップの開始時にジャーナルを使用して自分自身を修復するため、大したことではありません。そのセーフティネットがなければ、事態はさらに悪化します。それは単なるより多くのケースが優れているということではありません。
ジョー

回答:


97

デフォルトでは、ext2とその後継は、rootユーザーが使用するためにファイルシステムの5%を予約します。これにより、断片化が減り、管理者またはルート所有のデーモンが作業スペースを確保できなくなる可能性が低くなります。

これらの予約ブロックにより、ルートとして実行されていないプログラムがディスクをいっぱいにしないようにします。これらの考慮事項が容量の損失を正当化するかどうかは、ファイルシステムの用途によって異なります。

5%の量は、ディスクがはるかに小さい1980年代に設定されましたが、そのまま残されました。現在、システムの安定性にはおそらく1%で十分です。

コマンドの-mオプションを使用して、予約を変更できますtune2fs

tune2fs -m 0 /dev/sda1

これにより、予約ブロックの割合が0%(0ブロック)に設定されます。

(とりわけ)現在の値を取得するには、次のコマンドを使用します。

tune2fs -l <device> 

10
これは、使用可能なスペースの大きな違いを完全に説明します(2TBの5%が100GBであるため)。ディスクは、ルートまたはシステムファイルに関連するものとして使用されないため、これを無効にすると保存できると思います。しかし、私は質問を受けました:ルート所有プログラムは、非ルートプログラムよりも多くの空き容量があることをどのように知るのですか?df非ルートとして実行しても、ルートとして実行しても違いはありません。
紙吹雪

12
@confetti:VFSは(もちろんボリュームが実際にいっぱいになるまで)ディスクへの書き込み試行をエラーで拒否しないためです。
イグナシオバスケス-エイブラムス

1
tune2fs -l <device>とりわけこの値を与える必要があります。5%の量は、ディスクがはるかに小さい1980年代に設定されましたが、そのまま残されました。現在、システムの安定性にはおそらく1%で十分です。
harrymc

7
XFSは5%または8192ブロック(32 MiB)の小さい方を予約します。そのため、予約された量は一般にファイルシステムのサイズに比べて小さいです。
マイケルハンプトン

5
説明ありがとうございます。これは私が大いに理解するのを助けました。以前はディスクが最後のバイトまで完全にいっぱいでしたが、システムが完全に故障することはありませんでした。その理由がわかりました。
紙吹雪

3

格納するデータが圧縮可能な場合、compress=zstd(またはcompress-force=zstd)でマウントされたbtrfs はおそらくext *よりもかなり少ないディスク容量を使用します

  • これにより、btrfsはデータをディスクに書き込む前に透過的に圧縮し、読み取り時に透過的に解凍します。また、ext4はファイルシステムの作成時にすべてのiノードを事前に割り当て、btrfsは必要に応じてそれらを作成します。

1
この回答にさらに情報を追加してもよろしいですか?(それがどのように機能するか、それが何をするか、たぶん参照、...)
紙吹雪

@confettiはこんな感じ?patchwork.kernel.org/patch/9817875
hanshenrik

私はこのアイデアが本当に好きですが、これが速度とパフォーマンスにどのように影響するかについての詳細情報は素晴らしいでしょう。
紙吹雪

2
@confettiは、ハードドライブを使用しているため、おそらくパフォーマンスが向上します。CPUはハードドライブよりも非常に高速であるため、ディスクアクセスの遅い部分はデータをディスクに出し入れします。圧縮または解凍に費やされた時間は目立たないでしょう。
マーク

2
一方、現在のほとんどの種類の大きなファイル(画像、オーディオ、ビデオ、最もリッチなテキストドキュメント形式など)は既に圧縮されている傾向があり、一般に追加の圧縮の恩恵を受けません。少なくとも、ファイルシステムレベルで実行される単純な汎用の種類ではありません。
イルマリカロネン

3

まだ話されていないもう1つのポイントは、ファイルシステムに予約するiノードの数です。

デフォルトでは、mkfsは多数のiノードを作成します。これにより、非常に小さなファイルを大量にファイルシステムに配置できるようになります。ファイルが非常に大きくなり、FSに少数のファイルのみを配置することがわかっている場合は、iノードの数を減らすことができます。

世話をする!この数(スペースとiノードの数の比率)は、ファイルシステムの作成時にのみ設定できます。FSを拡張する場合でも、比率は変わりません。


また、大量の非常に小さなファイルを保存することがわかっている場合は、inodeの数を増やし、ブロックサイズを小さくして、スペースを無駄にしないようにすることができます。(1バイトであっても、各ファイルは少なくとも1ブロックを消費する必要があります。サイズとディスクで使用されているものを比較するには、ls -lsを使用します。)
Perkins

@Perkinsあなたは正しいですが、これは非常に小さなファイルにのみ当てはまると思います:デフォルトのブロックサイズは4kiB(IIRC)で、最小値は1 kiBです。ディスクが本当にそれらのファイルでいっぱいであることを除いて、それほど勝つことはありません。しかし、それでも、明日はこれに飛び込むかもしれません。
glglgl

2
または、必要に応じてiノードを作成するbtrfsを使用します。一方、ext4のiノードはファイルシステムの作成時に割り当てられ、作成後にサイズを変更することはできません(40億のハード制限)。最大のext4:pのハード制限よりも数倍高い
hanshenrik

usenetスプールの設定を思い出させます。ext4は、iノード自体に小さな(多くのものに応じて60〜160バイトの制限があります)を格納します。
mr.spuratic

@hanshenrikあなたはbtrfsにも同じブロックサイズの制限があることに注意してください(それを回避するいくつかの追加の方法があります)ので、保存するファイルの種類(大きいまたは小さいまたは両方)最大量のストレージを絞り出したい場合は、それに応じてファイルシステムを調整してください。ふわふわしたデータを保存している場合でも、自動圧縮の可用性は非常に役立ちます。
パーキンス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.