Why is `private.img` kept around for volumes with `revisions_to_keep = 0`?

User Support
1

I’m on btrfs instead of lvm-thin.

When I have a volume revisions_to_keep 0, why is private.img still kept around when the VM is running? Why not only keep private-dirty.img? I’m having some issues with low IOPS and I wonder if having 2 CoW copies of the same volume is slowing things down.

This volume is also quite large and the metadata ends up occupying a lot of space. The reflink copy that happens on shutdown takes a really long time. Is there a way to avoid the useless copying-around of metadata when there’s only ever going to be 1 copy of the volume? btrfs filesystem defragment helps for a while, but that takes a long time itself and it isn’t a permanent solution.

2

Unfortunately a problem with R4.2 which made me switch back to LVM

maybe you can find some sort of workaround/fix?

1 Like
3

That’s essentially how any storage driver is (currently) supposed to behave:

1 Like
4

I’m actually still on 4.1. If this is an additional problem on 4.2, then I’m glad I dragged my feet on upgrading. The volume in question is 4TiB.

Thanks for the link to the issue. Beyond just a “thumbs up” on GitHub, is there any formal way to suggest an issue be prioritized?

5

There aren’t any relevant R4.2 changes in this area, AFAIK.

Assuming that @Johnboy had comparable workloads in R4.1 and R4.2 (as opposed to e.g. having a more fragmented volume image file in R4.2, as measured by filefrag), the only thing that comes to mind is that he incidentally moved to a newer kernel with the R4.2 upgrade, and that this new kernel version has some sort of pathological interaction with his SSD hardware.

No, thumbs up reactions are great and they can be queried like: is:open label:"T: enhancement" sort:reactions-+1-desc

2 Likes
6

I understood that the test of @Johnboy showed very clearly that the fresh install with default settings vs. BTRFS made all the difference. How could the kernel version have been the root cause, when he switched from a working non-BTRFS 4.2 to a broken BTRFS 4.2 and then back to a working non-BTRFS 4.2?

I’m also planning to do a reinstall with default settings within the next days.

Any settings I should/could check before doing this?

7

Since Btrfs and LVM exercise very different code paths in the kernel (with that presumably resulting in equally different patterns of communication with the SSD), I wouldn’t be surprised if a kernel change affected one and not the other. That doesn’t even mean that the kernel should necessarily take the blame - or not as the root cause anyway: Drive firmware can be… quirky.

But this is just speculation.

Yes: