Feature #14697


Port OpenZFS Log Spacemap Improvements

Added by Jason King almost 2 years ago. Updated over 1 year ago.

zfs - Zettabyte File System
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


From OpenZFS #12789:

Improve log spacemap load time

Previous flushing algorithm limited only total number of log blocks to
the minimum of 256K and 4x number of metaslabs in the pool. As result,
system with 1500 disks with 1000 metaslabs each, touching several new
metaslabs each TXG could grow spacemap log to huge size without much
benefits. We've observed one of such systems importing pool for about
45 minutes.

This patch improves the situation from five sides:
- By limiting maximum period for each metaslab to be flushed to 1000
TXGs, that effectively limits maximum number of per-TXG spacemap logs
to load to the same number.
- By making flushing more smooth via accounting number of metaslabs
that were touched after the last flush and actually need another flush,
not just ms_unflushed_txg bump.
- By applying zfs_unflushed_log_block_pct to the number of metaslabs
that were touched after the last flush, not all metaslabs in the pool.
- By aggressively prefetching per-TXG spacemap logs up to 16 TXGs in
advance, making log spacemap load process for wide HDD pool CPU-bound,
accelerating it by many times.
- By reducing zfs_unflushed_log_block_max from 256K to 128K, reducing
single-threaded by nature log processing time from ~10 to ~5 minutes.

As further optimization we could skip bumping ms_unflushed_txg for
metaslabs not touched since the last flush, but that would be an
incompatible change, requiring new pool feature.

Reviewed-by: Matthew Ahrens <>
Reviewed-by: Brian Behlendorf <>
Signed-off-by: Alexander Motin <>
Sponsored-By: iXsystems, Inc.

Actions #1

Updated by Electric Monk over 1 year ago

  • Gerrit CR set to 2209
Actions #2

Updated by Joshua M. Clulow over 1 year ago

Because we've had a few serious regressions when importing patches from OpenZFS before, I think we'll need to do some due diligence here.

We don't want to miss any prior related changes on which this depends, and we don't want to miss any subsequent fixes that have been made to counteract regressions this may have caused. To be sure, I think it would help to start with the full list of files modified by this change, and walk both forwards and backwards in the OpenZFS history to look for potentially related changes. For each, we should either rule it out as unrelated, or investigate and potentially include it in this integration.

Another checklist item to consider is: does this change the on-disk format in any way?

Another is: has this change made it into an OpenZFS release, or is it just in master? If it is not yet in a release, we need to be extremely careful, because as far as I know the OpenZFS project doesn't make any strong guarantees about code that has not yet made it into a release.


Also available in: Atom PDF