実行時にマウントされた（非論理）パーティションのサイズ変更/移動ができないのはなぜですか？
検索中に、マウントされたパーティションのサイズを変更できない理由私は主に次のような答えを見つけました：
これはファイルシステムとパーティションに依存し、異なるファイルシステムとパーティションは異なる方法を使用します。 -- Javier Riveraによる
まず、基盤となるブロックデバイスを拡張する必要があります。 単一のハードディスクで従来のパーティションを使用している場合、これは不可能です。LVMとmdadmでブロックデバイスを拡張できる場合は、resize2fsを実行できます。 fsを展開します（ext [234]であると仮定します）。 -- psuiによる
使用しているファイルシステムによって異なりますが[...]、マウントされた使用可能なパーティションのサイズを変更することは強くお勧めしません。 -- ルイス・アルバラード作
Nonは、なぜそれが不可能なのか（誰も尋ねなかったため）、ファイルシステムに依存している、またはパーティションが論理ボリュームでない場合はまったく不可能であると述べているだけです。
マウントプロセスの内部動作とオペレーティングシステムのパーティション/ファイルシステムの処理についてはまったく知りませんが、パーティション化プログラムがユーザーにを要求できないのはなぜかと自問します。 ）すべてのプロセスを閉じるそしてその後は残りのプロセスと必要なデータのコピーをRAMに保持し、パーティションをアンマウントしてサイズを変更します。
ファイルシステムはいくつかのカーネルAPIを実装しています。そのため、名前でファイルを開く、ファイルに書き込む、ファイルから読み取る、ファイルを再度閉じる（これらの基本的な操作に固執する）機能を提供する必要があります。
カーネルは、セクターを読み取り、セクターを書き込むための関数を提供します。
その間の魔法は、ファイルシステム「ドライバー」によって行われます。したがって、プログラムがファイルを開きたい場合、カーネルはその要求をファイルシステムドライバーに渡します。次に、ドライバーはファイルシステムのメタデータを読み取り、ファイルのエントリを見つけます。エントリには、ユーザーとグループの所有権、アクセス許可、アクセス時間などのファイルシステム情報、およびもちろんファイルがディスク上にあるセクターに関する情報が含まれます（ここでは断片化を無視しましょう）。
したがって、パーティション全体を取得してディスク上の別の場所に移動すると、保存されているすべてのセクター番号にオフセットがありますが、ファイルシステムはこのオフセットを認識していません。したがって、プログラムがファイルを開こうとすると、ファイルシステムはファイルシステムのメタデータに格納されているセクター番号を使用してファイルの内容を読み取ります。ただし、ファイルシステム全体がさらに数セクター移動すると、読み取られたデータがファイルの内容に対応せず、ファイルが破損します。同じことがファイルシステムの他のすべてにも当てはまります。
カーネルはこれについて何も知りません。運転手がセクターを読むように頼む。カーネルは、セクター番号にオフセットが必要かどうかを認識していません。したがって、これはすべてのファイルシステムドライバに実装する必要があるものです。
ここで、16ビットを使用してセクターをアドレス指定する（レガシー）ファイルシステムを想像してみてください。セクターが512バイトであると仮定しましょう。したがって、ファイルシステムの最大サイズは32MiBにすることができます。ファイルシステムをさらに拡張する場合は、アドレス指定可能なセクターのサイズを512バイトから1024バイトに変更する必要があります。しかし、現在でも、すべてのセクター番号が使用されているため、ファイルシステムはいっぱいです。したがって、ファイルシステム拡張プログラムはすべてのファイルをスキャンし、サイズが1024バイトで512バイトしか使用されていない2つのセクターを1つのセクターにコピーして、一方のセクターが（再び）いっぱいになり、もう一方のセクターを解放できるようにする必要があります。
ここで、ファイルシステムがマウントされ、プログラムがディスクとの間で正常に読み取りおよび書き込みを行っているときに、これを実行する必要があると想像してください。これにより、この特別なユースケースでのみ必要となるファイルシステムドライバーがかなり複雑になります。したがって、マウントされていない場合にのみファイルシステムのサイズを変更する方が簡単です。
さらに、ボンネットの下にはさらに多くの魔法があります。たとえば、ファイルを作成し、開いて削除することができます。ファイルにはファイルシステム内の表現がありません（ファイル名はありません）が、開いている記述子がまだ存在するため、ファイルの読み取りと書き込みを行うことができます。記述子を保持しているプログラムがforksの場合、子も記述子を継承するため、そのファイルにアクセスできます。そのファイルに対して開いているすべての記述子がclosedになるとすぐに、ファイルシステムはセクターを未使用としてマークし、新しいファイルに使用できるようにします。
したがって、ファイルシステムをunmountしてから、もう一度mountすると、それらのファイルは失われます。そして、プログラムは立ち往生しています。
実際には、isマウント中に多くの最新のファイルシステムのサイズを変更することが可能です（ただし、通常はサイズを大きくする場合のみ）。例えば：
- From
man resize2fs： "resize2fsプログラム...を使用して、マウントされていないファイルシステムを拡大または縮小できます...ファイルシステムがマウントされている場合は、マウントされているファイルシステムのサイズを拡張するために使用できます..。 「」 - From
man xfs_growfs： "拡張するにはファイルシステムをマウントする必要があります。" - From
man mount： "jfsのマウントオプション... resize =value...ボリュームのサイズをvalue /に変更ブロック。JFSはボリュームの拡大のみをサポートし、縮小はサポートしません。」 - From BTRFS Fun ：「はい、これはオンラインのサイズ変更です。アンマウント/シュリンク/マウントする必要はありません。ダウンタイムはありません！」
AFAIK、ReiserFSはマウント時にサイズ変更できません。
ボリュームをアンマウントせずにサイズ変更する機能は、ミッションクリティカルなサーバーなどにとって非常に重要です。たとえば、Webホスティングプロバイダーは、ファイルシステムを追加した後にサイズを変更するためにファイルシステムをオフラインにするために必要なダウンタイムを許容できません。 RAIDアレイへの新しいディスク。そのため、多くの最新のファイルシステムがこの機能をサポートしています。
とはいえ、GPartedはパーティションをアンマウントせずにサイズを変更することはできません。私は前向きではありませんが、それはファイルシステム側よりも方程式のパーティション側に関係しているのではないかと思います。または、GPartedの開発者が保守的で、最小公分母の要件を設定していた可能性があります（つまり、ReiserFSの場合）。
ファイルシステムがLVMセットアップに保存されている場合、ファイルシステムのサイズ変更を処理する方が間違いなく簡単です。このタイプの構成では、ファイルシステムの開始点を移動する必要がないため、論理ボリュームとそれに含まれるファイルシステムを、必要に応じて、以前は存在していたファイルシステムが占有していたスペースにまで拡張できます。しかし、あなたが削除したこと。 LVMは、論理ボリュームへの動的な変更を念頭に置いて設計されていますが、カーネルによるパーティションの処理はより静的です。ファイルシステムを頻繁に調整する場合は、必ずLVMを調べる必要があります。 LVMには少し学習曲線がありますが、高度なファイルシステム操作や頻繁なファイルシステム操作を行う人にとっては、面倒なことをする価値があります。