Re: 12 TB btrfs file system on virtual machine broke again (fourth time)

[Chris Murphy <lists@colorremedies.com>]

On Mon, Jan 13, 2020 at 12:41 PM Christian Wimmer
<telefonchris@icloud.com> 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