1. Can you play with zfs_free_min_time_ms ? Default value is 1/5 of the txg
sync time (zfs_txg_timeout).
unsigned int zfs_free_min_time_ms = 1000; /* min millisecs to free per
txg */
Also It could be that reading metadata for freeing is slow (due to ARC
constraints or heavy I/O or fragmented pool on HDD) and this also could lead to
side effect then metadata cannot be read effectively enough to be ready within
zfs_txg_timeout seconds and blocks’ freeing is postponed to the next spa-sync.
Look at dsl_scan_async_block_should_pause() for details.
2. Don't you have set checkpoint on the pool ? It can break reclaiming if there
was no enough space, look at spa_suspend_async_destroy() for more details.
3. Don’t you have enabled dedup ? Data blocks can be referenced in this case
and will not be freed.
BTW, Do you see "zpool get freeing $pool” shows 150TB ?
———
Vitaliy Gusev
> On 1 Jun 2020, at 21:34, Schweiss, Chip <c...@innovates.com> wrote:
>
> These are ZFS folders that were destroyed. Snapshots and all.
>
> zfs destroy -r {folder}
>
> It is not instant. This too goes on the delete queue which recycles blocks in
> the background.
>
------------------------------------------
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/T51c43cca03b19c45-Ma07e1e4834f7d0beee8cf45c
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
