microzap: set hard upper limit of 1M

[robn]

[Sponsors: Klara, Inc., Wasabi Technology, Inc.]

Motivation and Context

We were running tests with large zap_micro_max_size, and could easily trip the panic in mzap_addent().

Description

The count of chunks in a microzap block is stored as an int16_t (zap_num_chunks). Each chunk is 64 bytes, and the first is used to store a header, so there are 32767 usable chunks, which is just under 2M. 1M is the largest power-2-rounded block size under 2M, so we must set the limit there.

How Has This Been Tested?

echo 16777216 > /sys/module/zfs/parameters/zap_micro_max_size
zpool create tank ...
cd /tank
seq 1 1000000 | xargs touch

This will panic consistently until the tunable value gets down to 1M. With this patch, its safe.

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.

[allanjude]

I was confused for a minute, you meant int16_t, ok.

[allanjude]

The on-disk component is:

        uint16_t mze_chunkid;

Is there a reason we use a signed value in memory?
Changing that would let us get to 2 MB, although I am not sure how much value that has

[robn]

Last push updates code and commit comment.

It turns out it can actually survive at max 2M. Adding entry 32768 causes a hash collision though, which immediately triggers an upgrade to fatzap. So that really does make 1M the practical upper limit.

@allanjude It might be possible to update everything to use unsigned ints internally to get to 2M (not sure about the hashing), but that would still be a problem if the block is used on an older ZFS (import or replication). The feature flag will help with that after 2.3 of course, but still.

(at this point I'm tempted to deprecate this tunable entirely).

[amotin]

Looks good to me. But on a quick look I haven't noticed any difficulties with making the 3 variables unsigned either, just to not have artificial the limits in future.