Today I was testing different parameters of ‘qemu-img convert’ in order to migrate a physical windows install into a virtual machine without passing the entire drive to the VM (which works really well, I tried that first).
Through this process, I was rapidly creating and deleting 600-900 gb files onto an m.2 drive. After a few iterations, my conversions started to error out with something about the drive being full.
This is when I learned about how deleting files in linux works. Practical from a stability perspective, very annoying in this moment. After some quick reading I figured that a reboot would restart whatever process was holding onto these delinked files, but a couple reboots didn’t change anything.
So I said ‘I’ll just copy everything I want to keep off and format the drive’. After the reformat, I couldn’t copy the files back as the drive was reporting as completely full. So I rebooted again, and . . .
This was an install that I created specifically for testing, so nothing was lost or needs to be recovered. But all if this testing is in preparation for a linux/vfio migration, so I’d like to understand what happened so I can not do it again when it matters.
Not sure whetger Fedora is doing something different from a normal distro, but if you rm a file using the rm command there’s nothing holding to it. If you have written a program that opens a file, writes into it and then does not close the file, you may get into something similar, but sure it won’t need a reboot, and you can use lsof to mist which files a process/user has currently open…
You said you formatted your drive, so it’s normal that after a reboot the system won’t boot?
If I understand correctly, Fedora uses btrfs as the default file system, and i suspect you trashed it somehow. “creating and deleting 600-900 gb files” and copy-on-write does not sound good; if I wanted to do that sort of thing I would be creating and deleting subvolumes. I wouldn’t trust the fs at all, and would wipe and make a new file system, say using gparted.
A btrfs can get in a state where any attempt to mount it hangs; I had one, after various misadventures due to a mobo problem, that hung even if I booted an ancient sysrescuecd iso using a really old 4.x kernel on another computer.
The boot drive (SATA) could not be booted from after I formatted a secondary drive (nvme) and rebooted. My mistake, I realize this morning that I hadn’t made that clear.
It never occurred to me that Feroda wouldn’t use the ext4 filesystem that I was used to with Debian. Subvolumes sound great too, I hadn’t heard of those either.
After doing a little more reading this morning, I think my problem came from my use of 'qemu-img convert -o RAW. Somehow I thought that it would manage itself and play nicely like any other file, but that might not actually have been the case.
@wizarddata Hey there, I frequest the Fedora Forums and while this forum is extremely helpful, You should post this problem there. You’ll get responses catered more to the distro and possibly more succinct answers.
As a matter of fact, you can just click Edit Post > and then copy all the info from your OP on to the forum.
