問題の本質：高度な仮想化を備えた仮想化システム（これは、openvzを無視するためです）は、仮想マシンを仮想ディスクの形で提供します。 または、より正確には、仮想ブロックデバイス。 おとぎ話がエミュレートされる場合（VMWareサーバー、Virtual PC）、「未定義のブロックデバイス」、場合によってはプレーンテキスト「仮想ディスク」（Xen for PVマシン）がエミュレートされます。 このデバイスがブロックデバイスのプロパティを完全に繰り返すことが重要です。これは、読み取りと書き込みが可能な一連のセクターです。
ほとんどの仮想化システムでは、ディスクのサイズを変更できます。 多くのシステムでは、オンラインで外出先でこれを行うことができます。
問題は、ゲストOSがこの場所を自由に使用できるかどうかです。 この質問は仮想化を超えており、一般的な質問です。通常モードでサイズを動的に変更できるファイルシステムはありますか？
まず、ほとんどのファイルシステムは外出先で成長できると言わなければなりません。 XFS、raiserr、ext3-4 ...一部のファイルシステムは縮小できます（ext3、raiser ... xfsはその方法を知りません）。 ここでのWindowsは、特にシステムディスク上のNTFSファイルシステムのサイズ変更をサポートしていないため、完全なアウトキャスターのように見えます。 サードパーティのユーティリティはこれを実行できますが、外出先ではできません...
しかし、白くてふわふわのext3でさえ、通常モードでこれを行う方法を知りません。 あなたは手で「断ち切る」と言う必要があり、上げる（特に下げる）プロセスには膨大なリソースが必要です。 私の個人的な印象では、通常のSATAディスクでは、4 TBの占有スペースを持つファイルシステムの5.5 TBから4.5 TBにサイズ変更すると、約10〜12時間かかります。 数分で増加は速くなります。 しかし-パフォーマンスは同じですが、負荷が大きく、負荷が非常に長くなります。
はい、アプローチ自体は間違っています。 使用領域のサイズを動的に変更する場合、通常のFS動作モードで未使用領域を自発的に解放し、必要に応じて新しい領域を要求するメカニズムが必要です。
既存のソリューション
私の知る限り、ブロックデバイス用のそのようなファイルシステムはまだありません。 唯一の解決方法は、ファイルベースのネットワークアクセスを使用することです。つまり、UnixにはNFS / SMBを、WindowsにはSMBを使用します。
私が理解しているように、ブロックデバイスの場合、「オンデマンドでの増加」の質問のみが部分的かつ限定的に解決されます。これは、使用する予定よりも明らかに大きいスパース（スパース）ディスクイメージファイルを使用して行われます。彼は実際の空間のより大きなボリュームを占有し始めます。 ただし、ゲストOSの場合、このディスクのサイズは変更されません（実際に占有されているスペースよりも大きい間）。 この方法では、ファイルシステムの機能を完全に考慮せず、イメージファイルの断片化を招き、空き領域を放棄することはできません。
本当に必要なもの
ファイルシステムはできるだけ小さくする必要があります。 2GBの場合、ファイルシステムのサイズは2GB +サービスデータです。 サイズが100 TBのファイルを作成することにした場合、ファイルシステムは、基礎となるレベルのブロックデバイスから4 kbの250億ブロックを要求し、ファイルを配置します。 ファイルが消去されると、ファイルシステムは250億を戻します。
「LVM」が思い浮かびますが、LVMは現在、ファイルシステムからのリクエストをサポートしておらず、FSの真ん中から穴を開ける準備ができていません...
ご質問
質問1：同様の解決策があるファイルシステムはありますか？
質問2：ファイルシステムとブロックデバイスのインターフェースはどのように見えますか？
質問3：ブロックデバイスを、一方でファイルシステムを作成して使用できるタイプの仮想デバイスに置き換え、他方で動的なサイズ変更により適合させることを想像できますか？
質問4：そのようなデバイスはどのように見えますか？