[zfs-discuss] Zfs destroy slow with dedup on (there should be enough RAM+L2ARC)

Gregor Kopka zfs-discuss at kopka.net
Wed May 4 06:08:12 EDT 2016


Could you, by chance, have destroyed deduped datasets while dedup=on and
non-deduped datasets while dedup=off?

Other thing that could come into play is that the DDT could have been
pulled into RAM on the first destroy so the requests for them could be
served from there after you set dedup=off.

Or base load of the drives (available IOPS) with dedup is already near
100% and the additional destroy drives them into stalling, while without
dedup the base load is lower and the destroy dosn't lead to all
available IOPS being consumed?

Can you toggle slowness of the server, while destroying non-deduped
datasets, by toggling dedup?
How busy are the drives in both cases?
How is ARC configured, arcstats, ddt statistics?
ZFS and other stuff version?

Gregor

Am 03.05.2016 um 21:09 schrieb Pentium100 via zfs-discuss:
> Hi,
>
> My backup server is a bit short on space, so I enabled dedup on it.
> The pool is about 45TB, the server has 96GB of RAM and 512GB SSD for
> L2ARC (secondarycache set to metadata). Not all RAM is currently in
> use and about 1.5GB of L2ARC is in use.
>
> New writes to the pool seem fast enough, however, when I tried to
> delete some old snapsohts/datasets (created before dedup was enabled)
> the server became very slow, free space increasing slowly. However, if
> I set dedup to off and then destroy the datasets, it works much faster.
>
> Why is that? Shouldn't destroying a dataset take the same amount of
> time independent on whether dedup is enabled at the time of the
> deletion (and only depend on whether the dataset itself is deduped)?
>
> While I can set dedup to off before deleting old data (and set it back
> to on again afterwards), this seems weird to me.
>
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20160504/a999a4b1/attachment.html>


More information about the zfs-discuss mailing list