limetech

Still says up to 5.6 but I'll include in next release.

Where do you see that 5.9 will be next LTS?

Nice report but I'd like to ask you to past as a separate bug report.

Please post separate bug report.

Depending on timing maybe you were seeing the results of a 'sync' to write that blocks of your copy to storage? Are most of the writes during normal operations (where you say 200GB/day) originating from docker containers or your VM's? Also, this discussion really should be a bug report because I will lock this topic with next release and not refer back to it.

Further clarification: it's not necessarily that bad because btrfs will gather other such writes into the newly allocated block group, but depending on I/O it can end up writing more due to metadata updates as well.

Also for completeness: You cannot turn on the C bit for an existing file. Well you can turn it on but btrfs will not now revert to NoCOW for the file. It must be turned on at the time the file is created before any data is written to it. The easiest way to accomplish this is to set the C bit on the parent directory. Though if you look at /usr/local/sbin/mount_image you will see what we do is create a zero-length file, set the C bit, then use fallocate to extend to the requested size.

To clarify a bit: if you want to copy say, "vdisk1.img" from one share to another you need to first set the NoCOW bit on the directory which will receive the file. For example: # /mnt/backup/domains/win10/vdisk1.img - is backup of img file # /mnt/cache/domains - is where we want to copy the vdisk.img file mkdir /mnt/cache/domains/win10 chattr +C /mnt/cache/domains/win10 cp --sparse=always /mnt/backup/domains/win10/vdisk1.img /mnt/cache/domains/win10 # --sparse-always is optional By virtue of C bit set on /mnt/cache/domains/win10 all files henceforth copied there will have the C bit set also.

How did you do the transfer? It's possible the "NoCOW" bit is not set for disk images, that is, the docker.img and all your VM vdisk images. If this is the case, all writes to these image files will result in btrfs copy-on-write operations. Since btrfs uses 1GiB block-group size, if say a docker container writes a single 4K block that will result in btrfs actually writing a 1GiB block (copy block group which contains the 4K block, update the 4K block, write the entire 1GiB block group to a new location). This is why we turn on NoCOW bit when images are created via webGUI. But if you simply used 'cp' command or similar, the target file will probably not have NoCOW bit set unless the directory you're copying to has NoCOW set. You can use the 'lsattr' command to see if NoCOW bit is set for a file, for example: # here is C bit (nocow) set on directory root@test-1:/mnt/images/domains# lsattr ---------------C---- ./win10-1 ---------------C---- ./ubuntu # here is C bit set on file root@test-1:/mnt/images/domains# lsattr win10-1/ ---------------C---- win10-1/vdisk1.img Note also you can create different pools, for example, to separate VM vdisk images from the Docker image. The downside with having NoCOW set is that btrfs turns off checksumming for the file (but contrary to misinformation out there, you can still create reflink copies of NoCOW files and snapshots of subvolumes with NoCOW files).

Too much going on in there. You need to simplify the config and see what makes it fail. Start by booting in safe mode.

Oops right, meant to have: cp /var/log/syslog /boot/syslog.txt Cats were on my mind I guess

Please capture the system log: cat /var/log/syslog /boot/syslog.txt That will put syslog.txt in root of usb flash boot device.

On-board sound is hardware dependent and generally problematic - some get it to work, some don't (same with onboard GPU). Likewise for anything USB related, much better off stubbing the entire usb controller and pass the controller to the VM instead of individual usb devices, especially anything more complex than a mouse or keyboard.

You should be able to get rid of file 'config/vfio-pci.cfg' on the flash and then reboot. This has been reworked quite a bit in 6.9 - you now use System Devices page to stub pci devices.

There is something misconfigured, please post diagnostics.zip.