Pour la dédup, la réponse a déjà été apportée...
Pour le checksumming, c'est une sécurité supplémentaire pour détecter des corruptions. Ca peut paraitre "ceinture-bretelle-caleçon blindé" mais étant donné que le FS ne peut pas totalement faire confiance au disque, cela permet d'être sûr qu'une écriture a bien été faite et surtout correctement, éventuellement de la corriger le cas échéant...
Pour la COW (Copy-on-write), le problème vient du fait que lors de la création d'un snapshot... le snapshot n'est qu'une COW-table (en gros)... pour toute modif est sur l'élément original (un LV par exemple), on reporte d'abord la data avant modif dans la cow table... puis ensuite on vient remplacer la data original par la nouvelle data... pour faire simple... une écriture génère: une lecture + une écriture + écriture.... je vous laisse estime la charge que cela peut générer sur de pauvres disques mécaniques.. si vous chaînez les snap, c'est la fin du monde ;-)
Le dump de dataset c'est à peu près "récupérer tel quel sur un autre disque" à ceci prêt qu'on ne peut pas parler de "disque"... en gros, tu peux dupliquer (ou dumper dans un fichier) ton dataset dans l'état du dernier snapshot que tu as fait.
L'intérêt étant le dump différentiel permettant de ne transférer vers le dataset distant, que ce qui a changé depuis le dernier snapshot, d'où la notion de réplication asynchrone (car non temps-réél)
Le scrubbing, c'est une assurance que tes données sont intègres. Encore une fois, c'est l'usage (prod ou non) qui fera que cela sera utile. Le scrubbing ne fait pas d'analyse de surface des disques, il fait une analyse de l'intégrité des données du zpool. Si ton zpool n'a que 3To d'utilisé sur 12To total, le scrub ne se fera que sur 3To. Donc, on n'a pas d'équivalent hardware du scrubbing, il faut plutôt voir le scrubbing comme un fsck en ligne (sur la partie data occupée).
[^] # Re: Zfs vs BTRFS
Posté par marsupilamies . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 4.
Pour la dédup, la réponse a déjà été apportée...
Pour le checksumming, c'est une sécurité supplémentaire pour détecter des corruptions. Ca peut paraitre "ceinture-bretelle-caleçon blindé" mais étant donné que le FS ne peut pas totalement faire confiance au disque, cela permet d'être sûr qu'une écriture a bien été faite et surtout correctement, éventuellement de la corriger le cas échéant...
Pour la COW (Copy-on-write), le problème vient du fait que lors de la création d'un snapshot... le snapshot n'est qu'une COW-table (en gros)... pour toute modif est sur l'élément original (un LV par exemple), on reporte d'abord la data avant modif dans la cow table... puis ensuite on vient remplacer la data original par la nouvelle data... pour faire simple... une écriture génère: une lecture + une écriture + écriture.... je vous laisse estime la charge que cela peut générer sur de pauvres disques mécaniques.. si vous chaînez les snap, c'est la fin du monde ;-)
Le dump de dataset c'est à peu près "récupérer tel quel sur un autre disque" à ceci prêt qu'on ne peut pas parler de "disque"... en gros, tu peux dupliquer (ou dumper dans un fichier) ton dataset dans l'état du dernier snapshot que tu as fait.
L'intérêt étant le dump différentiel permettant de ne transférer vers le dataset distant, que ce qui a changé depuis le dernier snapshot, d'où la notion de réplication asynchrone (car non temps-réél)
Le scrubbing, c'est une assurance que tes données sont intègres. Encore une fois, c'est l'usage (prod ou non) qui fera que cela sera utile. Le scrubbing ne fait pas d'analyse de surface des disques, il fait une analyse de l'intégrité des données du zpool. Si ton zpool n'a que 3To d'utilisé sur 12To total, le scrub ne se fera que sur 3To. Donc, on n'a pas d'équivalent hardware du scrubbing, il faut plutôt voir le scrubbing comme un fsck en ligne (sur la partie data occupée).