Je retiens comme ordre de grandeur ce qui est donné en conclusion dans ton 2ième lien :
These are all fictitious numbers, YMMV, but I think some good rules of thumb are:
If performance isn't critical, and if you expect to save more than 20% of storage capacity through deduplication, then go for it but add at least 5GB of L2ARC SSD capacity per TB of pool data to store the dedup table in.
If performance is important, wait until you expect at least a 2:1 reduction in storage space through deduplication, and add 30GB of RAM to your system for every TB of disk capacity to make sure that the dedup table is always in memory so optimal write performance is ensured..
Cela-dit la dedup n'est pas possible que via zfs et btrfs. Il existe aussi d'autres solutions que je n'ai pas testé comme opendedup, lessfs ou permabit VDO.
Mais est-ce que ces solutions peuvent être considérée comme robustes/fiables ? Déjà que Btrfs, il faut y aller avec des pincettes... Quand je vois tout ce qu'il faut pour faire confiance à un FS : performance OK dans tous les cas de figure, outils de récupération fonctionnels, comportement en cas de corruption, upgrade sans problème lors de la mis à jour du noyau, etc.
[^] # Re: Pas trop étonné
Posté par SaintGermain . En réponse au journal Obnam est abandonné. Évalué à 3.
Je retiens comme ordre de grandeur ce qui est donné en conclusion dans ton 2ième lien :
Mais est-ce que ces solutions peuvent être considérée comme robustes/fiables ? Déjà que Btrfs, il faut y aller avec des pincettes... Quand je vois tout ce qu'il faut pour faire confiance à un FS : performance OK dans tous les cas de figure, outils de récupération fonctionnels, comportement en cas de corruption, upgrade sans problème lors de la mis à jour du noyau, etc.