QEMU Harddisk no devices, no file system but files still accessible

Question

I'm running a Proxmox as my Hypervisor, where I set up my 6 TB disk as a ZFS pool. Then I created a virtual disk and attach it to VM running Ubuntu Server 20.04 where it shows up as a QEMU Harddisk. I believe all this information it's not all that relevant as the problem is within the VM and has nothing to do with the Host machine nor the type of storage used, although, I might be mistaken.

So, once inside the VM, back in the day, I created an ext4 partition and mounted normally. I allocated about 2 o 3 TB since I thought I could easily expand the Virtual Disk and enlarge the partition. Well, that was the case for a while, but suddenly I might had messed something up the device /dev/sdc1 disappeared with its file system. Although, the drive could still be mounted and all files where there.

These are the outputs I get after running "fdisk -l", "parted" and "partprobe". The disk shows up as having a loop partition and no devices (/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

As you can see, the disk /dev/sdb of 931.51 GiB have a "Disklabel type" and "Disk indentifier", as well as a partition labeled as /dev/sdb1 with a file system of "Linux" (ext4). This is not the case for the disk /dev/sdc of 3.93 TiB. Is missing the Disklabel type", "Disk indentifier" and fdisk doesn't show any partitions. Although, parted does shows a partition table of type "Loop" and one partition with ext4.

This has been running for a long while like that, the only thing I'm noticing is pretty poor performance. At tops 20 MB/s even on sequential writes and even less If it's serving files over Plex or Torrents, when the drive was capable of at least 140 MB/s. I guess this performance might be due to the "lack" of a file system or whatever is going on in the partition table.

Anyway, I was wondering If there's any way to fix this without reformatting the whole, since I don't have any spare HDD large enough to store all the files. By "fix" I mean to create a partition with its file system. Or to change the current partition table from "Loop" to GPT or MRB/DOS and then create a partition and a file system.

If that's not possible, just let me know, and I will just back up the essential files and try to find somewhere to store the rest.

• telometto: Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
• Asiier: @telometto I have tried to clarify the issue as good as I could. Hopefully is more understandable.
• Asiier: @cas My bad. I have already changed it.
• telcoM: In parted, partition type loop means "raw disk access". This suggests there is no partition table on the disk. It is possible to use the whole disk for a single filesystem by creating a filesystem on /dev/sdc instead of /dev/sdc1 - perhaps you originally did this accidentally? If you run file -s /dev/sdc, what is the output?
• Asiier: @telcoM I might have done that one of the times I expanded the disk from Proxmox. Here is the output: ➜ ~ 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)

Answer 1

In the comments you showed the output of 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)

That indicates the disk has indeed been set up with no partition table at all. With data disks of VMs, this can actually be an advantage: it allows you to expand the filesystem immediately after the virtual disk has been expanded, with no need to bother with modifying the partition table.

Just tell the host system to expand the virtual disk, then maybe echo 1 > /sys/block/sdc/device/rescan in the VM if your virtualization platform did not already inform the VM about the disk expansion automatically, and then you can just expand the filesystem to fill the (expanded) virtual disk with resize2fs /dev/sdc.

The poor performance is probably not caused by the lack of a partition table; in fact omitting the partitioning makes disk access very slightly simpler, if anything.

You should find out what type of drivers your virtualization environment allows your VMs to use. If the environment allows you to use paravirtualized (virtio) drivers, those might perform orders of magnitude better than having the virtualization host emulate a particular model of a physical storage controller for the VM.