Too many snapshots vs performance

[danboid]

You may recall my ZFS LTSP server with over 700 datasets in its home dir pool that has slowed to a crawl. There were over 600K snapshots on the pool and it took over a month to destroy them all but now that all of the snapshots have been removed the server is still running horribly slowly.

I was hoping that destroying all of the snapshots would reverse the damage caused by having too many but it doesn't seem to have made any difference. Is this your understanding of too many (destroyed) snapshots vs performance?

scrubs just check data integrity and don't do any kind of "defrag" or optimization do they? Is there no equivalent to defrag for ZFS that could spare me having to destroy and recreate the pool to regain the performance? I think thats my only option here.

Thanks Jim

[redmop]

This problem isn't related to sanoid, so you are going to get better help if you go to one of the openzfs places to get support. When you do ask for ZFS support, include the system specs, drive type, and pool space, and zfs pool vdev config in every ticket you open. You will get better and faster answers if you have already provided that information so others don't have to dig, or ask these questions and wait for a response.

No, there is no defrag for ZFS. Google that for more information.

[danboid]

I realise this isn't a sanoid bug as such although it was caused by sanoid not pruning snapshots. I thought Jim would've come across this situation before which is why I asked here.

[MynaITLabs]

I had a similar situation on our 'backup' server (all the zfs snapshots from other servers are syncoided to a central server).
Where prune wasn't working (the config file accidentally had 'prune=no') for several months and the number of snapshots approached 1 million. (No wonder the server was slow when doing any zfs commands).

After I re-enabled pruning, the sanoid auto-pruning took about three to four days to clean up the mess (competing with all the other regular system tasks ). Fragmentation gradually went down over the next few weeks but didn't change much after a month.

Luckily we had enough disk space, to be able to copy a complete dataset and all the snapshots to another new temp location on the same zfs server then delete the original and rename the temp to the original name. That helped fragmentation significantly.
(NOTE: remember to turn off snapshots and any backup scripts so no new snapshots don't get in the mix during the shuffle!)