free_space_estimate: adjust for compression on btrfs #1301
Conversation
|
Note I think in theory we should do the same for filesystems on LVM with VDO compression enabled, but that looks a bit harder and we don't need it right now, so I skipped it. :P |
|
ehhh, I worry there might be an ordering problem between the class definition and the flag setting here, actually. mmmf. edit: ok, re-done, I think using methods like this should mean we use the current state of the flag whenever an estimate is requested, which should be...mostly correct. |
AdamWill
force-pushed
the
space-estimate-compression
branch
from
aab5dcb
to
869b7a8
Compare
We have a problem with Fedora aarch64 KDE disk images ATM. We want to make them 16 power-of-ten gigabytes big, so they will fit on "16GB" SD cards / USB sticks. When we set them to this size, compose fails because the anaconda free space check fails, saying "An additional 436 MiB is needed". That check is ultimately backed by this estimate. In these images, the main system partition is a btrfs volume, with compression enabled. If you examine the last successful image (which was built at size 18 power-of-two GB), thanks to compression, only ~5GB of space is actually occupied on that volume. The contents would easily fit if it were slightly smaller. With this change we adjust the free space estimate by a compression factor, as well as a metadata factor, if the class defines one. For the btrfs class we set it to 1.4 when the compression flag is set. That's a pretty conservative estimate, we will usually achieve a much better compression ratio with a typical OS payload (as the numbers above show). AFAICT this codepath is only actually used by the anaconda size check, so the change should be fairly safe. Signed-off-by: Adam Williamson <awilliam@redhat.com>
AdamWill
force-pushed
the
space-estimate-compression
branch
from
869b7a8
to
dabec2a
Compare
|
Jenkins, ok to test. |
|
huh. is the centos 9 failure real or some kinda test system blip? it does seem like it failed in a related test, but the log shows no info on the failure and seems like it just sorta blew up in a cloud of java? |
That's just the VM dying during the test execution, it sometimes happens, our testing infrastructure has some random issues unfortunately. The Java exception is Jenkins losing connection in the middle of execution. |
We have a problem with Fedora aarch64 KDE disk images ATM. We want to make them 16 power-of-ten gigabytes big, so they will fit on "16GB" SD cards / USB sticks. When we set them to this size, compose fails because the anaconda free space check fails, saying "An additional 436 MiB is needed". That check is ultimately backed by this estimate.
In these images, the main system partition is a btrfs volume, with compression enabled. If you examine the last successful image (which was built at size 18 power-of-two GB), thanks to compression, only ~5GB of space is actually occupied on that volume. The contents would easily fit if it were slightly smaller.
With this change we adjust the free space estimate by a compression factor, as well as a metadata factor, if the class defines one. For the btrfs class we set it to 1.4 when the compression flag is set. That's a pretty conservative estimate, we will usually achieve a much better compression ratio with a typical OS payload (as the numbers above show). AFAICT this codepath is only actually used by the anaconda size check, so the change should be fairly safe.