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 ;-)
Je ne comprends pas du tout...
De ce que j'avais compris les snap BTRFS (et je présume que c'est pareil avec ZFS), c'est juste annoter tous les inodes/block/je-sais-plus et sur l'utilisation courante continue à écrire les données sur de nouvelles plages plutôt que de les modifier (comme tu le décris plus haut). C'est juste qu'avec cette annotation, on sait qu'on ne va pas libérer ce block/inode. Donc ça coûte l'annotation de tous les blocs lors de la création et rien pour l'utilisation courante. Et ça c'est déjà du COW.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Zfs vs BTRFS
Posté par barmic . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 3.
Je ne comprends pas du tout...
De ce que j'avais compris les snap BTRFS (et je présume que c'est pareil avec ZFS), c'est juste annoter tous les inodes/block/je-sais-plus et sur l'utilisation courante continue à écrire les données sur de nouvelles plages plutôt que de les modifier (comme tu le décris plus haut). C'est juste qu'avec cette annotation, on sait qu'on ne va pas libérer ce block/inode. Donc ça coûte l'annotation de tous les blocs lors de la création et rien pour l'utilisation courante. Et ça c'est déjà du COW.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)