.png)
そのため、さまざまな理由により、パーティション テーブルがなく、28 TB のデータ (ファイル システム自体は 28 TB) を含む NTFS としてフォーマットされた 45 TB の単一 Linux 論理ボリュームが作成されました。
ファイルシステムは Linux で作成され、Linux でマウント可能です。問題は、同じボックス上の KVM ベースの Windows VM 内にこれをマウントしようとすると発生します。Windows は 28TB のファイルシステムではなく、ランダムなサイズの役に立たないパーティションがいくつか含まれた 1.8TB のディスクを認識します。
これは、Windows が実際の NTFS ファイルシステム データの最初の数バイトをパーティション テーブルとして読み取ろうとしているためだと思われます。
この問題の解決策はいくつか考えられますが、実際にどのように実行すればよいのかわかりません。
- Windows はパーティション化されていないディスク (単一ボリューム) をファイルシステムとして読み取りますか?
- ファイルシステム自体に保持されているデータを破壊せずに、この論理ボリューム上に何らかの方法でパーティション テーブルを生成しますか?
- 何らかの方法でパーティション テーブルを偽造し、LVM ボリュームを指し示し、これを KVM ゲスト (libvirt で実行) にエクスポートします。
parted によって報告される現在の「パーティション テーブル」は次のとおりです。
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/chandos--dh-data: 48.0TB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0.00B 48.0TB 48.0TB ntfs
答え1
私も、ディスクではなくパーティションを誤ってイメージ化してしまったという同様の問題に遭遇しました。イメージはネットワーク経由でコピーされていたため、再度コピーする時間がありませんでした。ただし、サイズは 28 TB よりはるかに小さく、イメージのコピーを作成する必要があるプロセスを使用しました。
最初の画像は以下を使用して撮影されました:
dd if=/dev/sda1 of=/image.bin
パーティション テーブルを追加するには、ネットワーク経由ですべてをコピーせずに、MBR だけをファイルにコピーしました。
dd if=/dev/sda of=/mbr.bin bs=512 count=1
次に、mbr を先頭に追加し、データをコピーしました。
fdisk -l /mbr.bin
# take the start position * units in bytes (ex start at 256 * units of 512 bytes = 131072 bytes)
truncate -s (disk size in bytes + number of above) /newfile.bin
dd if=/mbr.bin of=/newfile.bin
dd if=/image.bin of=/newfile.bin oflag=seek_bytes seek=(number from above)
完了すると、/newfile.bin完全なパーティション テーブルとデータが含まれます。
答え2
実は、これに対する良い解決策は見つかっていません。幸い、約 30 TB のスペースがある別のドライブ シェルフが手元にあるので、これを使用して新しくパーティション分割されたボリュームに移行できます。時間はかかりますが、うまくいくはずです。
何か賢いことができるかもしれないという提案があった。Linux デバイス マッパー(LVM 論理ボリュームと並行して、ファイルから偽の GPT パーティション テーブルをマップする仮想デバイスを作成します) が、これはもっと賢い人に解決してもらいます。
編集：実際にこれに対する解決策を書きましたここ
答え3
2TB を超えるディスクでは GPT パーティション テーブルを使用する必要があります。2TB 未満のディスクでは MBR で十分です。