QEMUハードディスクにはデバイスやファイルシステムはありませんが、ファイルにアクセスできます。

QEMUハードディスクにはデバイスやファイルシステムはありませんが、ファイルにアクセスできます。

私はProxmoxをハイパーバイザーとして実行しており、6TBディスクをZFSプールに設定しました。その後、仮想ディスクを作成してUbuntu Server 20.04を実行している仮想マシンに接続し、そこでQEMUハードドライブとしてマークされています。問題がVM内にあり、ホストや使用されているストレージの種類とは関係がないため、これらすべての情報はあまり関連性がないと思います。もちろん、私が間違っている可能性があります。

そのため、VMの内部に一度ext4パーティションを作成し、正常にインストールしました。仮想ディスクの拡張とパーティションの拡大が容易なようで、2~3TB程度割り当てました。まあ、これはしばらく続いてきましたが、突然/dev/sdc1デバイスを台無しにし、そのファイルシステムが消えた可能性があります。それでもドライブをマウントでき、すべてのファイルがそこにあります。

これは、「fdisk -l」、「parted」、および「partprobe」を実行した後に得られる出力です。ディスクにループパーティションがあり、デバイスがないように見える(/dev/sdcX)

➜  ~ fdisk -l
...

Disk /dev/sda: 50 GiB, 53687091200 bytes, 104857600 sectors
Disk model: QEMU HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 368BBA10-0FA4-4ED3-898D-30F65B772EC7

Device     Start       End   Sectors Size Type
/dev/sda1   2048      4095      2048   1M BIOS boot
/dev/sda2   4096 104857566 104853471  50G Linux filesystem


Disk /dev/sdb: 931.52 GiB, 1000203091968 bytes, 1953521664 sectors
Disk model: QEMU HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdbcabab3

Device     Boot Start        End    Sectors   Size Id Type
/dev/sdb1        2048 1953521663 1953519616 931.5G 83 Linux


Disk /dev/sdc: 3.93 TiB, 4294967296000 bytes, 8388608000 sectors
Disk model: QEMU HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop8: 73.18 MiB, 76734464 bytes, 149872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

➜  ~ parted /dev/sdc
GNU Parted 3.3
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sdc: 4295GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system  Flags
 1      0.00B  4295GB  4295GB  ext4

➜  ~ partprobe -s /dev/sdc
/dev/sdc: loop partitions 1

ご覧のとおり、931.51 GiBディスク/dev/sdbには「ディスクラベルタイプ」と「ディスク識別子」があるだけでなく、ファイルシステムが「Linux」(ext4)の/dev/sdb1ラベル付きパーティションもあります。 3.93 TiBディスク/ dev / sdcの場合はそうではありません。 「Disk Label Type」、「Disk Identifier」が欠落しており、fdiskにパーティションは表示されませんが、Partedには「Loop」タイプのパーティションテーブルとext4パーティションが表示されます。

これは長い間実行されており、私が気づいた唯一のことはパフォーマンスが悪いことです。順次書き込みの場合でも、速度は最大20 MB /秒に達することができ、PlexまたはTorrentを介してファイルを提供すると、ドライブは少なくとも140 MB /秒の速度に達することがあります。私はこのパフォーマンスがファイルシステムの「不足」によるものであるか、パーティションテーブルで起こっている可能性があると思います。

とにかく、すべてのファイルを保存するのに十分な空き容量のあるハードドライブがないため、ファイル全体を再フォーマットせずにこの問題を解決する方法があるかどうか疑問に思います。 「修復」とは、ファイルシステムでパーティションを作成することを意味します。または、現在のパーティションテーブルを「Loop」からGPTまたはMRB / DOSに変更して、パーティションとファイルシステムを作成します。

これが不可能な場合は、お知らせください。必要なファイルをバックアップし、残りの部分を保存する場所を参照してください。

ベストアンサー1

コメントで次の出力を示しましたfile -s /dev/sdc

/dev/sdc: Linux rev 1.0 ext4 filesystem data, UUID=3cd41499-e6d0-470f-88c1-e828beb07f42 (needs journal recovery) (extents) (64bit) (large files) (huge files)

これは、ディスクが実際にパーティションテーブルなしで設定されていることを示します。仮想マシンのデータディスクの場合、これは実際には利点です。つまり、パーティションテーブルを変更せずに仮想ディスクを拡張した後、すぐにファイルシステムを拡張できます。

ホストシステムに仮想ディスクを拡張するように指示し、仮想化echo 1 > /sys/block/sdc/device/rescanプラットフォームが仮想マシンにディスク拡張について自動的に通知しない場合は、仮想マシンでファイルシステムを拡張して(拡張)仮想ディスクを作成できます。resize2fs /dev/sdc

パフォーマンスの低下の原因は、パーティションテーブルがないためではない可能性があります。実際にパーティションを省略すると、ディスクアクセスが少し簡単になります。

仮想化環境が仮想マシンにどのタイプのドライバを許可するかを調べる必要があります。環境で準仮想化(virtio)ドライバを使用できる場合、これらのドライバのパフォーマンスは、仮想化ホストがVMの物理ストレージコントローラをエミュレートする特定のモデルよりはるかに優れている可能性があります。

おすすめ記事