Set aside a metaslab for ZIL blocks

[ahrens]

Motivation and Context

Mixing ZIL and normal allocations has several problems:

1. The ZIL allocations are allocated, written to disk, and then a few
   seconds later freed. This leaves behind holes (free segments) where the
   ZIL blocks used to be, which increases fragmentation, which negatively
   impacts performance.

2. When under moderate load, ZIL allocations are of 128KB. If the pool
   is fairly fragmented, there may not be many free chunks of that size.
   This causes ZFS to load more metaslabs to locate free segments of 128KB
   or more. The loading happens synchronously (from zil_commit()), and can
   take around a second even if the metaslab's spacemap is cached in the
   ARC. All concurrent synchronous operations on this filesystem must wait
   while the metaslab is loading. This can cause a significant performance
   impact.

3. If the pool is very fragmented, there may be zero free chunks of
   128KB or more. In this case, the ZIL falls back to txg_wait_synced(),
   which has an enormous performance impact.

These problems can be eliminated by using a dedicated log device
("slog"), even one with the same performance characteristics as the
normal devices.

Description

This change sets aside one metaslab from each top-level vdev that is
preferentially used for ZIL allocations (vdev_log_mg,
spa_embedded_log_class). From an allocation perspective, this is
similar to having a dedicated log device, and it eliminates the
above-mentioned performance problems.

Log (ZIL) blocks can be allocated from the following locations. Each one is
tried in order until the allocation succeeds:

1. dedicated log vdevs, aka "slog" (spa_log_class)
2. embedded slog metaslabs (spa_embedded_log_class)
3. other metaslabs in normal vdevs (spa_normal_class)

The space required for the embedded slog metaslabs is usually between 0.5% and
1.0% of the pool, and comes out of the existing 3.2% of "slop" space that is
not available for user data.

How Has This Been Tested?

On an all-ssd system with 4TB storage, 87% fragmentation, 60% capacity, and
recordsize=8k, testing shows a ~50% performance increase on random 8k sync
writes. On even more fragmented systems (which hit problem #3 above and call
txg_wait_synced()), the performance improvement can be arbitrarily large
(>100x).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[don-brady]

Is the selection of the embedded_log_class dynamic? (i.e. at each spa_import?). I'm trying to understand how zdb instance of the pool knows which ms to use for embedded log and if it can be different from what the runtime pool is using?

If zdb can know the actual ms, then a follow on zdb change could augment the zdb -m output by tagging the embedded log ms.

[ahrens]

Yes, the metaslab is selected when opening the pool. So zdb wouldn't necessarily select the same metaslab as was used recently (or is currently in use, if the pool is imported while running zdb). But typically, on pools that have moderate or higher fullness or fragmentation, the zil metaslab will really stick out as it will be the only one that's (nearly) empty and unfragmented.

[sempervictus]

I've had this running on a couple test VMs for a week or so - they haven't blown up and do seem to have lower pool fragmentation rates in overwritten pools getting beat up with a bunch of fio scripts. The performance benefit on mostly-full pools is pretty noticeable (this is not on fast io subsystems by any means, ceph on encrypted bcache served up as a qemu volume) - iowait spikes aren't nearly as bad after a few fills.
How safe is the on-disk format for pulling the code into a production branch?

[ahrens]

@sempervictus Thanks for your testing, glad it's working well for you! There's no on-disk format change, so the PR code should be safe to use in production. (We just "happen" to choose different places to allocate ZIL vs other blocks, and the ZIL metaslab is determined each time the pool is opened.) FYI, we have been using a slightly different version of this in the Delphix product for over a year.

[sdimitro]

LGTM just a couple of questions around small vdevs.

[mmaybee]

Modulo Serapheim's concern that there may be cases where you try to passivate a null metaslab pointer with small pools, everything looks good.