I have not seen yet how much better dedup2 in Solaris is,
but the current Open-ZFS implementation has the following problems
- You must keep the dedup table in any case in RAM as this is realtime
dedup
otherwise a pool import or snapshot delete can last ages and performance
can become unusable slow.
- it requires a lot of RAM that you want to use for cachingand performance.
Depending on data we talk about 1-5 GB RAM / TB dedup data(that is
required additionally to your cache demands).
- while you can enable on a filesystem level it operates on pool level.
once activated you cannot disable beside a pool destroy.
In the end, it may be a good idea but only when you have enough RAM and
very high dedup rates (say >5-10)
that are much better then the compress rate with lz4
Mostly the dedup rate is not good enough compared to a larger pool with
lz4 dedup
where you do not need to care about the dedup restrictions.
gea
@napp-it.org
Am 03.05.2018 um 09:22 schrieb Oliver Weinmann:
Hi,
I always hear people saying don’t use dedup with ZFS. Is that still
the case? We use omnios as a VEEAM backup target and I would assume
that using dedup would save a lot of disk space.
Best Regards,
Oliver
*Oliver Weinmann*
Head of Corporate ICT
Telespazio VEGA Deutschland GmbH
Europaplatz 5 - 64293 Darmstadt - Germany
Ph: +49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
oliver.weinm...@telespazio-vega.de
<mailto:oliver.weinm...@telespazio-vega.de>
www.telespazio-vega.de
Registered office/Sitz: Darmstadt, Register court/Registergericht:
Darmstadt, HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
