From 65b8bb62522f5799b566b07a50a35ff853c6cccb Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Thu, 24 Aug 2023 13:09:05 -0400 Subject: [PATCH] transposefs: Only autosave-xfs for much larger filesystems The change in https://github.com/coreos/fedora-coreos-config/pull/2320 has been very problematic for OpenShift because our default node configuration is *always* over the threshold, and that causes significant latency on instance provisioning. Experimentally bumping to 400 allocation groups, which is about 700GiB. This is comfortably about the default OpenShift node root disk sizes, and returns us to the prior status quo. While we're here, rework the logging a bit so that we *always* log the `agcount` for debugging purposes. --- .../ignition-ostree-transposefs.sh | 17 ++++++++++++----- .../kola/root-reprovision/autosave-xfs/test.sh | 7 +++++-- 2 files changed, 17 insertions(+), 7 deletions(-) diff --git a/overlay.d/05core/usr/lib/dracut/modules.d/40ignition-ostree/ignition-ostree-transposefs.sh b/overlay.d/05core/usr/lib/dracut/modules.d/40ignition-ostree/ignition-ostree-transposefs.sh index 6f89c4007e..3ba12a6602 100755 --- a/overlay.d/05core/usr/lib/dracut/modules.d/40ignition-ostree/ignition-ostree-transposefs.sh +++ b/overlay.d/05core/usr/lib/dracut/modules.d/40ignition-ostree/ignition-ostree-transposefs.sh @@ -139,13 +139,20 @@ should_autosave_rootfs() { return fi local agcount + # We want to run xfs_info on the unmounted filesystem, because actually just + # even mounting an XFS filesystem that has grown an excessive number of allocation groups + # can be very slow. eval $(xfs_info "${root_part}" | grep -o 'agcount=[0-9]*') - # Semi-arbitrarily chosen: this is roughly ~64G currently (based on initial - # ag sizing at build time) which seems like a good rootfs size at which to + # This is roughly ~700GiB currently (based on initial ag sizing at build time) which + # seems like a good rootfs size at which to # discriminate between "throwaway/short-lived systems" and "long-running - # workload systems". It's not like XFS performance is way worse at 128. - if [ "$agcount" -lt 128 ]; then - echo "Filesystem agcount is $agcount; skipping" >&2 + # workload systems". Specifically for e.g. OpenShift, it's below the default node + # sizes. + local threshold + threshold=400 + echo "${root_part} agcount=$agcount" >&2 + if [ "$agcount" -lt "${threshold}" ]; then + echo "agcount=$agcount is lower than threshold=${threshold}" echo 0 return fi diff --git a/tests/kola/root-reprovision/autosave-xfs/test.sh b/tests/kola/root-reprovision/autosave-xfs/test.sh index a7760e5818..daefe0c521 100755 --- a/tests/kola/root-reprovision/autosave-xfs/test.sh +++ b/tests/kola/root-reprovision/autosave-xfs/test.sh @@ -1,9 +1,10 @@ #!/bin/bash ## kola: ## # This test reprovisions the rootfs automatically. +## # Tests: ignition-ostree-transposefs-autosave-xfs.service ## tags: "platform-independent reprovision" -## # Trigger automatic XFS reprovisioning -## minDisk: 100 +## # Trigger automatic XFS reprovisioning (heuristic) +## minDisk: 1000 ## # Root reprovisioning requires at least 4GiB of memory. ## minMemory: 4096 ## # This test includes a lot of disk I/O and needs a higher @@ -19,6 +20,8 @@ set -xeuo pipefail if [ ! -f /run/ignition-ostree-autosaved-xfs.stamp ]; then fatal "expected autosaved XFS" fi +# Verify we printed something about the agcount +journalctl -u ignition-ostree-transposefs-autosave-xfs.service --grep=agcount ok "autosaved XFS on large disk" eval $(xfs_info / | grep -o 'agcount=[0-9]*')