☰

大規模なExt4ドライブに通常推奨される予約済みブロック（ルート用）の数はありますか？

tag-icon • tag-icon root disk-usage ext4
大規模なExt4ドライブに通常推奨される予約済みブロック（ルート用）の数はありますか？

次の質問を通して：

大規模なExt4ドライブに通常推奨される予約済みブロック（ルート用）の数はありますか？

具体的には、次の点について言及しています。

  • 最近（ほぼ）誰もがかなり大きなルートドライブ（パーティション）を持っているとしましょう。

  • 1.8TiBルートパーティションを持つ2TBドライブを考えてみましょう。これは、最初のブートパーティションを除くドライブ全体が使用されることを意味します。

  • また、自分だけがこのコンピュータにアクセスでき、ハードウェアとオペレーティングシステムに直接アクセスできるとします。

  • 補足としてGRUBに特定の文書を設定しました。GRUB_CMDLINE_LINUX_DEFAULT="rootflags=data=journal"見つかりませんでした。ここに追加してみてください。。

これらすべてを実際のケースに適用するために、私のラップトップにあるNVMeドライブは次のとおりです。

# fdisk -l /dev/nvme0n1

Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 970 EVO Plus 2TB            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 989573D5-37E7-437A-B680-9410F7234A94

Device          Start        End    Sectors  Size Type
/dev/nvme0n1p1   2048     194559     192512   94M EFI System
/dev/nvme0n1p2 194560 3907028991 3906834432  1.8T Linux filesystem

2番目のパーティション/dev/nvme0n1p2はExt4ファイルシステムタイプです。考慮すべき値の完全なリストは次のとおりです。

# tune2fs -l /dev/nvme0n1p2 
tune2fs 1.46.5 (30-Dec-2021)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          f1fc7345-be7a-4c6b-9559-fc6e2d445bfa
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122093568
Block count:              488354304
Reserved block count:     20068825
Free blocks:              388970513
Free inodes:              121209636
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      817
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat Jun 16 11:26:24 2018
Last mount time:          Thu Oct 26 09:14:38 2023
Last write time:          Thu Oct 26 09:14:38 2023
Mount count:              102
Maximum mount count:      -1
Last checked:             Tue Sep 26 03:05:31 2023
Check interval:           0 (<none>)
Lifetime writes:          43 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
First orphan inode:       134214
Default directory hash:   half_md4
Directory Hash Seed:      48360d76-0cfb-4aed-892e-a8f3a30dd794
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x58d12a63

いくつかの予約されたルートスペースが必要か、そうであればどのくらい必要かを評価したいと思います。この質問がコメントに基づく質問ではないことを願っています。答えを追加することにした場合は、参考資料を追加してください。ありがとうございます。

ベストアンサー1

したがって、重要な理由はまったくありません。

最も簡単な理由は、root実行サービスがログおよび/またはデータをそのボリュームに保存して、ユーザーがドライブにデータが溢れても引き続き機能できるようにしたいということです。明らかに、これは次の場合にのみ意味があります。

  1. あなたが言及するボリュームは、実際にはルートとして実行されるプロセスで使用されます。
  2. また、ディスクをファイルで埋めてサービスの動作を拒否できないユーザーが使用します。
  3. 権限のないユーザーがユーザーデータを書き込むことができるよりも、サービスが実行され続ける方が重要です。

あなたのシステムはデスクトップシステムのようです。したがって、必要なものと正反対ではなくても、少なくとも3は問題があると言いたいと思います。

だから私はこれが非常に弱い主張だと思います。特に、多くのサービスが当初はrootとして実行されていないからです。

それから（ext4の「メイン」開発者によって提示された）もう一つの主張は、空き容量が少ない場合、ファイルシステムが新しいファイルまたは増加するファイルの連続ブロック領域を見つけるのが難しいということです。これはいわゆる分裂これは、回転するディスクストレージのハードウェアパフォーマンスの問題（より長い検索時間のため）であり、断片化されたファイルを保存および読み取るより複雑でリダイレクトされる方法のためにまだオーバーヘッドの問題です。ファイルシステムドライバは、ストレージ全体に分散したファイルをアプリケーションに連続して表示する必要があり、これにより、プリフェッチとキャッシュ機能がSSDのマイナーな問題として残ります。また、メタデータのサイズも増えます。私はメタデータの必要性が高まり、利用可能なスペースが少なくなるか、断片化されたファイルにアクセスするときにより多くのルックアップが必要かどうかを説明するのに十分なext4の内部構造を知りません。

https://listman.redhat.com/archives/ext3-users/2009-January/msg00026.html

スケジュールされたブロック数を0に設定すると、長時間実行（多くのファイルを作成および削除）し、ファイルシステムがほとんどいっぱいでない限り（95％など）、この時点で断片化の問題が発生します。

[… ]

ファイルが頻繁に変更されない長期アーカイブファイルシステム（大容量mp3やビデオストレージなど）を使用している場合、これは明らかに重要ではありません。

したがって、実際にはユースケースによって異なります。ファイルシステムが にマウントされているのを見ると、おそらくインストールした/すべてのソフトウェアがあるファイルシステムでしょう。大規模なソフトウェアアップデートは、多くのファイルが削除され生成される時期です。したがって、作成されたファイルと削除されたファイルのサイズがバランスをとるとき、平均して十分に隣接するストレージ部分から自由に選択できるように十分なスペースを確保することが合理的です。

では、その金額はどのくらいでしょうか？言いにくいただし、大規模な更新プロセスによって20 GBの変更（新しいファイル10 GB、古いファイル10 GBの削除）が発生する可能性があると仮定すると、これは実際に合理的な上限のように見えます。だから空間確保に役立つようです。

ファイルシステムサイズは1.86TBです。これは、NVMeがおそらくコンシューマ/プロシュマ1.92TBデバイスであることを意味します。現在、テラバイトあたりの実行価格は45〜80ユーロです。ヘッドルームを「最適化」することは、お金の面で精神的な空間の価値があるかどうかを再確認することをお勧めします。もちろん、78GBは必要以上に多くなります。しかし、その量が6.60ユーロ未満の場合、実際に十分であるかどうかを十分に検討していますか？

おすすめ記事