Prometheus 2.40 WAL segment size transition for low-traffic disk reduction

For a Prometheus instance handling roughly 10 samples per second, the goal is to lower the write-ahead log segment size from the long-standing 128 MiB default to a smaller value such as 8–16 MiB, using the --storage.tsdb.wal-segment-size flag introduced in version 2.40. The intent is to reduce the storage footprint and limit the amount of unreclaimed data during short scrape intervals without changing query behavior.

The uncertainty lies in how this configuration change interacts with existing retention boundaries defined by --storage.tsdb.retention.time and --storage.tsdb.retention.size, and whether the resulting increase in segment count and truncation frequency introduces unacceptable fsync or CPU overhead on the host. Because the flag is unavailable before 2.40, any mixed-version rollout or rollback plan must account for startup failures on older binaries, and practical verification of actual segment sizes and disk usage over a stable low-traffic period is required before production adoption.

What is the safest way to evaluate the trade-off between reduced disk usage and higher WAL checkpoint frequency for a low-traffic workload? Which retention settings should be re-examined before committing to the smaller segment size?