混乱しているので、誰かがこの問題を解決するのに役立ちますか?
1.8Tディスク(VM仮想ディスク)があり、以下はdfの一部です。
df -TH
Filesystem Type Size Used Avail Use% Mounted on
/dev/sdb ext4 1.8T 1.6T 91G 95% /af
パーティション情報は次のとおりです。
parted /dev/sdb print
Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 1924GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 1924GB 1924GB ext4
したがって、パーティションを最初に作成せずにファイルシステムが設定されたとします。これで拡張が必要になり、これは2TBの制限を超えています。これが問題になるかどうかはわかりませんか?私が理解したところによると、仮想ディスクのサイズを増やしても大丈夫で、拡張は単にファイルシステムを拡張してする必要がありますが、正しくして
resize2fs -f /dev/sdb
いるのでしょうか?
答え1
動作します。 ext4 は、自分のいるブロックデバイスがパーティションなのか、フルハードドライブなのか、LVMボリュームなのか、ネットワークブロックデバイスなのか、iSCSIのターゲットなのかは関係ありません。見えるものはすべてブロックです。
答え2
これは優雅さの観点から技術的に「クソ構成」ですが、問題にはなりません。単に.vdiまたは.vmdkのサイズを変更し、通常のサイズ変更のように処理することは大丈夫です。ただし、パーティション拡張フェーズをスキップできることは例外です。
仮想マシンなので、まずスナップショットを作成するか(仮想マシンソフトウェアでサイズ変更を許可する場合)、ファイルをコピーします。 2T VMがあるので、スペースは1〜2時間問題にならないようです。これは非常に手頃な価格の保険であるため、問題が発生するかどうか心配する必要はありません。
少し「奇妙」という点を除いて、技術的な「動作するかどうか」構成には何の問題もありません。ブロックデバイスはブロックデバイスです。さまざまなクイックインストール作業で同じ間違いを1〜2回犯しました。以前にこのようなことをしている会社で働いたことがあります。故意に何らかの理由で(主に神話的な)より速いかもしれません。 (1つの例外は、オンディスクパーティショニングツールなどを使用してファイルシステムの起動を損なうような愚かなことがない限りです。)
アプリケーションがこの問題を心配している場合は、ddを使用して最初の数メガバイトを別のFSのファイルに保存できます。このファイルはFSが更新されても同期を維持しないため、完全なバックアップではありませんが、簡単な予防策であり、ブートセクタの破損やその他の簡単なインストールから回復するための良い機会を提供します。今、この構成の奇妙な点を理解していたと思いますが、実際にはそれほど大きな問題にはなりません。
答え3
短い答えは「おそらく」です。
私はこれをext4で具体的にテストしていませんが、あなたのハイパーバイザーが何であるか/仮想ディスクのフォーマットが何であるかわかりませんが、確かにそうですEBSでXFSと連携。まず、使い捨ての仮想マシンでテストし、ターゲットを試す前にバックアップが良好であることを確認することをお勧めします(値がある場合)。
まず、ストレージのサイズを変更する必要があります。 qemuで「raw」イメージを使用している場合、これは可能ですが実行するのは難しいです。 ddを使用してヌルバイトロードを追加する必要があります。構文はやや難解です。注意してよく読んでください。 qcow2イメージを使用すると、はるかに簡単ですqemu-img resize yourdiskfile 2500G
。しかし、ここでは。場所さまざまなストレージベース/ハイパーバイザーのその他の可能性。
パーティションテーブルがないため、MBRの2Tb制限について心配する必要はありません。
新しい仮想マシンを構築するとき、私は常に(少なくともOSボリューム上の)パーティションテーブルを使用し、OSとは異なるボリュームにデータを保存します。