On Mon, Jan 13, 2020 at 12:41 PM Christian Wimmer <telefonchris@xxxxxxxxxx> wrote: > > Hi guys, > > just to update you. > > I tried a 4th time with a brand new 12 TB archive and right after setting up everything and putting some data on it I performed a controlled suspend and restore and so on and yes, it broke again with that terrible messages that it can not mount any more the file system. > > Then I decided to create only 2TB archives (hard disks) as the slider in the Parallels VM suggests to do. > I created 4 x 2TB files, one with persistent size and three expandable. > I filled up all hard discs with data and rebooted 5 times (even when writing data to it) and everything runs very stable. > > So to resume, the Parallels Virtual machine has a problem when the virtual disk is being selected bigger than 2TB. There is (and was) never a problem with the btrfs files system I think. > > Sorry for bothering you all the time with my bad setup. > > Thanks a lot for all your help! Yeah it's no problem. I mean, there's no way to know in advance that the setup is bad, it has to be proven. And with any complicated setup, it's really tedious to find out where the problem is happening. And even still it's not certain if this is some bug flushing to Parallels, or if it's getting the flush and not doing it completely for very large backing files, or if the host OS file system or block device drive is dropping something. There are definitely bugs in Btrfs too so you can't absolutely exclude the possibility, but those look different. They tend to be pernicious. Whereas in your case these problems appeared quickly, back to back. But also it's super complicated, multiple layers have to all work exactly right or there will be problems. I would be very skeptical of VM guest suspend with any file system. It should be true there is fs sync that happens when the guest kernel is told to suspend, but then what happens to that flush once it's in the VM or hypervisor? *shrug* How long does it take to actually get from VM all the way to stable media? Because necessarily you have to consider worst case scenario, like doing file writes and a complete loss of power. Since Btrfs and kernel block layers aren't directly responsible for writing to the disks, it's ambiguous exactly when and in what order, the writes do get to stable media. Ok so now what? It's entirely possible you've totally eliminated the problem. Or it might be possible you've only reduced the chance it'll happen - meaning something like it will happen at some point. Is it superfluous extra work for no benefit, to unmount this Btrfs file system, or use fsfreeze, prior to suspending the VM? Or never suspend the VM? Or maybe the non-default mount option flushoncommit is useful in this case? It's a huge hassle to have to rebuild a 12TB volume, it's a high penalty. -- Chris Murphy
