スケジュールされたブロックの問題:パーティションサイズが正常に変更されましたが、OSはそれを認識しません。

スケジュールされたブロックの問題:パーティションサイズが正常に変更されましたが、OSはそれを認識しません。

私はデュアルブートシステムを実行しており、LinuxディストリビューションはUbuntu 14.04です。

/dev/sda6私はGPartedを使用して、ディレクトリが通常マウントされる論理パーティションを拡張しました。/homeGParted レポートによると、操作は正常に完了しました。パーティションサイズは85GiBで、予想通り83GiBが使用され、2GiBが使用可能です(d)。

ところで、ここには2つの奇妙な点があります。

  1. そのバフはログイン後に認識されません。ディスク使用量チェックを有効にすると、df -hレポート/dev/sda6に正しくマウントされたパーティションサイズが/home85GiBで、そのうち83GiBが使用されていると表示されます。0利用可能。利用率は100%と言われています。

  2. もう1つの奇妙なことは、GUIを介して定期的にユーザープロファイルにログインできることです。ただし、資格情報が認識された後は、システムの動作が停止し、デスクトップ環境に切り替えられません。情報を取得するには、df -hテキスト端末に一般IDでログインするか、GUIからゲストとしてログインする必要があります。ところで、データが破損しているようではありません。

この状況をどのように解決できますか?目的は、パーティションサイズの増加をオペレーティングシステムで完全に使用できるようにすることです。助けてくれてありがとう。

ベストアンサー1

おそらく、extこれらのファイルシステム(通常はデフォルトのLinuxファイルシステムext4)の1つを使用しています。ほとんどの場合、作成時と呼ばれる特定のバッファを使用して生成されますreserved blocks。この予約済みスペースはシステムプロセスとルートによってのみ記録されるため、ユーザーディスクがいっぱいになることからオペレーティングシステムを保護します。

主な目的dfは、利用可能な合計ディスク容量の量を表示することです。 (ユーザーが)使用するスペースも表示しますが、予約されたスペースは表示しません。

デフォルトでは、このバッファはディスク全体の5%を占めます。そのようなバッファがあるかどうかを確認できますsudo tune2fs -l /dev/sda6 | grep Reserved。入力により、sudo tune2fs -l /dev/sda6 | grep [bB]locksBの予約済みブロック数とブロックサイズを読み取り、構造が占めるパーティションスペースを確認することもできます。これは、システムが85GiBとしてマークされていますが、83個のみが使用され、無料では0個のみが使用されることを示しています。

必要に応じて、バッファをより低い値に設定できますsudo tune2fs -m 2 /dev/sda6(2はパーセントサンプル値、デフォルトは5です)。

より良いオプションは、実際にサイズを変更して安全に十分な空きディスク容量を確保することです。 85GiBのうち2GiBはわずか2.35%です。これはあまりありません。ほとんどの場合、比較的早く埋められます。スペース使用量が83GiBで安定すると確信している場合は、tune2fsを使用して安全のために0%を予約できますが、ディスクがいっぱいになると(85GiBまで)すべての内容を記録できず、システムがクラッシュして修正するのが難しくなります。 。

5%安全マージンは比較的合理的な安全マージンです。したがって、この場合は、緊急事態に備えてパーティションを少なくとも90GiB、おそらく100GiB以上に設定します。ディスクスペースは安価ですが、ディスクがいっぱいになって発生する問題を解決するのにかかる時間ははるかに高価です。

答えこの問題推論についてより多くの洞察を提供します。

おすすめ記事