Beaglebone Blackファイルシステムのサイズ変更-誤った情報？ 「パーティションを削除して新しいパーティションを作成するだけです」
私はビーグルボーンブラックシステムを使ってリモートで作業しています。
ルートファイルシステムの拡張に関するこの情報をYouTubeで見つけました。
https://www.youtube.com/watch?v=FK6wfV_19ac （12:50から視聴）
ビデオの作成者は、/を含むファイルシステムを文字通り削除し、新しいパーティションを作成することにより、ファイルシステムのサイズ変更を示しています。
（私が完全に誤解していない限り？）
これは完全にクレイジーに思えます。これがどのように機能し、ファイルシステムを破壊しなかったのか理解できませんか？このプロセスでデータが破損しておらず、すべてのiノードがまだ有効であるというのは完全なまぐれのようです。
これは私が何かを完全に誤解したかどうか疑問に思います-そして今私はこれが実際に行うのに有効なことであると心配しています。
これについてセカンドオピニオンをお願いします-作者がビデオでファイルシステムを拡張する正しい方法を指示しているのですか？もしそうなら、なぜファイルシステムのルートのすべてのデータを含むパーティションを削除してもそのデータが破壊されなかったのですか？
パーティションとファイルシステムは同じではありません。ファイルシステムが破壊されることはありませんでした。
パーティションは、パーティションテーブルのエントリによって識別されるより大きなデバイスの一部にすぎません。 fdiskはこのテーブルを操作します。 DOS（MBR）のパーティションスキームでは、パーティションテーブルはディスクの先頭（厳密には：近く）にあります。 GPTでは、それは始まりに近く、（別のバックアップ）は終わりに近づいています。それはどのパーティションにも属していません、少なくともそうすべきではありません。ある意味では「目次」と考えることができます。
ファイルシステムは通常、パーティション内に存在する構造です（ただし、通常のファイルに存在する場合もあれば、デバイス全体を使用する場合もあります）。パーティションエントリがなくなった場合でも、 オフセットがわかっている場合はファイルシステムをマウントできます 。
ビデオの作成者はパーティションエントリを破棄し、新しいエントリを作成しました。これはパーティションテーブルにのみ影響し、（古いまたは新しい）パーティション内の実際のデータ、つまりファイルシステムには影響しませんでした。問題のパーティションはより大きく再作成されましたが、その開始セクターは残りました。ここからファイルシステムが始まります。
再起動後、ファイルシステムは正常にマウントされます。これは、カーネルが新しいパーティションの先頭でヘッダーを探すためです。これは、実際のファイルシステムヘッダーがあった/ある古いパーティションの先頭と同じです。ファイルシステムはそのサイズを認識しているため、ファイルシステムが「適合する」限り、パーティションのサイズが異なるという事実は関係ありません（したがって、拡大は常に問題ありません。最後の縮小に関する注記を参照してください）。
最後に resize2fsは、実際にファイルシステムのサイズを変更するために使用されました。新しいサイズが指定されていないため、ツールはファイルシステムにパーティション全体を取得させました。これは、ファイルシステム自体に何かが行われた唯一の瞬間でした（定期的なマウントとアクセスは別として）。このツールは、ファイルシステムがマウントされている場合でも、右へのサイズ変更をサポートします（つまり、ファイルシステムの先頭を移動しません）。これが起こったことです。
はい、それは正しい方法です。
パーティションを縮小する場合は、最初にファイルシステムを縮小してから、パーティションテーブルを調整する必要があることに注意してください。ルールはいつでもファイルシステム全体がパーティションに収まる必要があるということです。マウントされたファイルシステムの縮小は、拡張するほど簡単ではない（またはまったく不可能な場合があります）。