Feature: ZAP data structure to support shrinking, convert to Microzap

[DeHackEd]

System information

Type	Version/Name
Distribution Name	CentOS
Distribution Version	7.x
Linux Kernel	4.9.xxx-elrepo (custom build)
Architecture	x86_64
ZFS Version	Git (various)
SPL Version	n/a

Describe the problem you're observing

Over time, ZAPs structures (for the uninitiated, these are effectively hashtables as a fundamental ZFS data structures) grow to accommodate the entries added to them, but are never shrunk without being deleted and re-created. Often times this is difficult, impractical or even impossible to do.

I have personally seen a ZAP over 300 megabytes large containing 0 objects. Due to the nature of the hashtable this is a very fragmented data structure and sweeping the ZAP to find all 0 entries takes a long time on rotating media.

The usual advise of defragmenting a pool by send/recv doesn't shrink the ZAP since it is sent in its entirety, but does defragment it.

Other related discussions:
#3814 - Process 'zfs_unlinked_drain' asynchronously on mount
#5916 - Slow mount times due to enormous ZFS delete queue object
#4933 - Directory listing slow after it has contained many entires

Describe how to reproduce the problem

For example:

• Create a directory
• Fill the directory with many entries (ie millions). For speed reasons it may be best to make a single real file and fill the directory with hard links to it rather than making many files.
• Delete all files in the directory
• Purge the ZFS cache somehow - export/import, unmount + drop_caches, etc.
• Run ls on the directory. Observe the long time required to show 0 results.

Include any warning/errors/backtraces from the system logs

N/A

[rincebrain]

Let's also not forget #7401, which would have been a lot more fun if ZAPs were dynamically shrinking too. :)

[scineram]

It seems someone is working on this for illumos. Hopefully it gets upstreamed quickly.

[beren12]

90% done but no activity in 2 years :-/ https://code.illumos.org/c/illumos-gate/+/1580

[rincebrain]

#14088

[jumbi77]

FYI: #14088 is now replaced by: #15888
Looking forward to get this integrated. As far as I read here, its a separate PR which may get integrated separate to the big new "fast deduce" feature. I guess reviews are welcome :)