数週間前、今まで見たことのない何かに遭遇しました:パーティションのないストレージデバイスにインストールされたファイルシステム(ext3)です。本質的に /dev/sdb
wasファイルシステム全体。私は多くのファイルシステムが空のスペースに拡張できることを知っているので、これを行うと、LVMや他の種類のボリュームマネージャーを扱わずに拡張できますが、この方法でストレージを設定することには他の利点がありますか?
私が見た特定のケースは、数値計算サーバーの短命なデータボリュームであり、ブートボリュームとルートボリュームは、完全に別のストレージデバイス上の従来のパーティションでした。 -
長所:パーティションテーブルの1つのディスクセクターを無駄にしないでください。 (わーい。)
Pro:ディスクは、PCスタイルのパーティションをサポートしていないオペレーティングシステムで使用できます。 (これを使用するように)。
短所:これは異常であり、共同システム管理者を混乱させる可能性があります。 (見る?)
短所:別のオペレーティングシステムをインストールすると、ディスクにゴミが含まれていると考えられ、間違ったディスクを選択して誤って上書きしてしまう可能性があります。一方、オペレーティングシステムは通常、タイプがわからないパーティションをそのままにします。
無関係:ファイルシステムの拡張は、パーティションにある場合よりもディスクに直接ある場合の方が簡単ではなく、その逆も同様です。 (LVMを使用すると簡単になります。)
結論:機能しますが、お勧めできません。
これがLinuxにどのように適用されるかはわかりませんが、ネイティブZFSでは、パーティションではなくディスク全体にプールを作成することが推奨される1つの理由は、前者の場合、ディスク書き込みキャッシュを有効にできることです。
ここでも言及されている他のいくつかの理由:
http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools
結論:それは機能し、ファイルシステムによっては良いアイデアかもしれません。
これが仮想環境で行われると、本当のメリットがわかります。 VMDKはNASに保存されているため、動的に拡張できます。
パーティションを使用している場合は、LVM(およびそれに関連するオーバーヘッド)を使用してパーティションをチェーンするか、またはgpartedのようなものを使用するためにホスト(または使用されていない場合はファイルシステム)を停止する必要があります。
ただし、パーティションではなくディスク全体を使用する場合は、SCSIディスクを強制的に再スキャンし、resize2fsを使用して、オンライン(および使用中)の間にファイルシステムを拡張できます。
パーティションを作成せずにファイルシステムをディスクデバイスに配置することは、それほど珍しいことではありません。
利点:
Rawデバイス上のファイルシステムのサイズを変更できることは、正当な理由ではありません。この方法で節約したスペースは、他のものには使用できません。したがって、デバイス全体で直接ファイルシステムを作成できます。
記載されていない答えは、パーティションを作成しない場合、カーネルがそれを検出するのを待つ必要がないことです。これは再起動後にのみ可能性があります。
1つの使用例は、ノードに追加して最初の起動時に初期化するEC2 EBSボリュームです。
初期化プロセスでパーティションを作成すると、カーネルが新しく作成されたパーティションを表示するために再起動しなければならないリスクがあります。通常、次のようなメッセージが表示されます。
エラー:パーティション/ dev/xvde1への変更についてカーネルに通知するエラー-デバイスまたはリソースがビジーです。つまり、Linuxは、再起動するまで/ dev/xvde1に加えた変更を認識しません。したがって、再起動する前に、Linuxをマウントしたり、何らかの方法で使用したりしないでください。
この場合、初期化プロセスは再起動を実行してから、新しく作成されたパーティションにファイルシステムを追加し続ける必要があります。
必要なパーティションが1つだけであることがわかっている場合は、そのパーティションをスキップして、再起動が必要になるリスクを回避することもできます。