You set up automatic ZFS snapshots thinking you’re clever. You’ve got hourly recursive snapshots for the last month, and honestly, it works fine until your database dataset starts hitting a million files. Then, suddenly, listing files or running a simple find command takes an eternity. You aren’t imagining it, and it’s not the disk speed. It’s the metadata overhead of holding onto that many snapshots on a single filesystem.

Why the kernel hates your massive snapshot history

Every time you keep a snapshot, ZFS has to track block pointers. When you have thousands of snapshots on a directory structure with high churn, the metadata traversal gets heavy. The arc and the dnode cache get stomped on because the system is busy validating block references across your snapshot timeline. It’s essentially death by a thousand cuts for your lookup speed.

zfs list -t snapshot -o name,used,referenced | sort -k2 -h | tail -n 20

Cleaning up the mess without panicking

• Audit your snapshot retention policy and stop keeping hourly data for more than 48 hours
• Move long-term archival snapshots to a separate pool or dataset that isn’t under active write load
• Prune snapshots from the tail end first to reduce the metadata update pressure on the ARC
• Check your dnode settings if you consistently hit this performance wall on busy systems

If you are running into this, don’t just dump all your snapshots at once. You’ll induce a massive I/O wait spike that might lock your production applications. Prune them in batches, give the system a few minutes to reconcile the block pointers, and keep an eye on your iostat until the pool settles down. If you need a deep history for compliance, look at zfs send to external storage rather than pinning it to your active metadata heap.