Justement non, le fait que ZFS couvre à la fois les fonctionnalités de LVM, mdadm .... est un grand +.
Il n'y a pas de chaîne de confiance "aveugle" à la "FS <-> LVM <-> MDADM". La donnée est gérée de bout en bout par ZFS.
Dans le fonctionnement en couche habituelle, chaque couche du dessus fait "confiance" à la couche du dessous. Le FS doit considérer que si LVM lui indique que l'écriture est OK, il doit lui faire confiance. LVM fait de même avec MDADM qui fait de même avec les disques. Ce genre de chose peut aboutir à une possible corruption "silencieuse" (le fameux writing hole du raid 5 par exemple). J'ai personnellement vécu ça avec un RAID6 (EXT4-LVM-MDADM).
ZFS n'a, à ma connaissance, qu'un seul véritable concurrent: WAFL de Netapp. Ces 2 systèmes sont d'ailleurs franchement très similaire. Les 2 partagent d'ailleurs la fonctionnalité de ne jamais réécrire une donnée modifiée au même endroit que la donnée originale, ce qui permet en cas d'écriture incomplète, de certes perdre la donnée en cours d'écriture, mais de conserver l'ancienne donnée et non pas une donnée corrompue, le pointeur n'étant mis à jour que lors de l'écriture complète de la nouvelle donnée (cf RAID 5 writing hole).
Par contre, tout çà à un coût niveau perf. Ce filesystem n'est pas fait pour obtenir les meilleures perf... mais plutôt garantir au maximum la cohérence et la pérénité de la donnée.
Côté fonctionnalité, soyons clair:
- La compression, ça fonctionne très bien, sous réserve de prévoir de la ressource CPU. Dans certain cas, on obtient d'ailleurs de meilleures perfs que sans, sur des disques mécaninques lents.
- la dédup, étant online, est très consommatrice de RAM et "tue les perfs". Il faut l'utiliser avec parcimonie.
- le checksummming, parfait pour garantir la cohérence de data très importante
- le snapshot, sans perte de performance car ne fonctionnant pas en mode copy-on-write (contrairement à LVM, ce qui impose une utilisation temporaire des snaps et une impossibilité de les chainer sans effondrer les perfs)
- le dump des datasets (zfs send/receive) pour transférer le contenu d'un dataset vers un autre dataset zfs (distant ou local) ou vers un fichier. Possibilité d'utiliser le send incrémentale entre 2 snapshots.
- le scrubbing, vérification de l'intégrité des DATAs présentent dans le zpool.
- à vous de voir pour les autres fonctionnalités.....
Par contre, gros "mauvais point", pas de possibilité d'étendre des RAIDZ (1,2 ou 3). Il faut aggréger un nouveau RAIDZ (et de taille identique si possible, pour ne pas créer d'asymétrie au niveau IOs). Contrairement à WAFL qui a son RAID DP basé sur le RAID 4 (+1 parité supplémentaire), qui lui utilisant des disques dédiés aux paritées, permet l'ajout de disque à une grappe RAID.
Voilà, en espérant avoir éclaircit la lanterne de certains sur ce FS qui mériterait vraiment une utilisation "large" tellement il offre de possibilités.
[^] # Re: Zfs vs BTRFS
Posté par marsupilamies . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 10.
Justement non, le fait que ZFS couvre à la fois les fonctionnalités de LVM, mdadm .... est un grand +.
Il n'y a pas de chaîne de confiance "aveugle" à la "FS <-> LVM <-> MDADM". La donnée est gérée de bout en bout par ZFS.
Dans le fonctionnement en couche habituelle, chaque couche du dessus fait "confiance" à la couche du dessous. Le FS doit considérer que si LVM lui indique que l'écriture est OK, il doit lui faire confiance. LVM fait de même avec MDADM qui fait de même avec les disques. Ce genre de chose peut aboutir à une possible corruption "silencieuse" (le fameux writing hole du raid 5 par exemple). J'ai personnellement vécu ça avec un RAID6 (EXT4-LVM-MDADM).
ZFS n'a, à ma connaissance, qu'un seul véritable concurrent: WAFL de Netapp. Ces 2 systèmes sont d'ailleurs franchement très similaire. Les 2 partagent d'ailleurs la fonctionnalité de ne jamais réécrire une donnée modifiée au même endroit que la donnée originale, ce qui permet en cas d'écriture incomplète, de certes perdre la donnée en cours d'écriture, mais de conserver l'ancienne donnée et non pas une donnée corrompue, le pointeur n'étant mis à jour que lors de l'écriture complète de la nouvelle donnée (cf RAID 5 writing hole).
Par contre, tout çà à un coût niveau perf. Ce filesystem n'est pas fait pour obtenir les meilleures perf... mais plutôt garantir au maximum la cohérence et la pérénité de la donnée.
Côté fonctionnalité, soyons clair:
- La compression, ça fonctionne très bien, sous réserve de prévoir de la ressource CPU. Dans certain cas, on obtient d'ailleurs de meilleures perfs que sans, sur des disques mécaninques lents.
- la dédup, étant online, est très consommatrice de RAM et "tue les perfs". Il faut l'utiliser avec parcimonie.
- le checksummming, parfait pour garantir la cohérence de data très importante
- le snapshot, sans perte de performance car ne fonctionnant pas en mode copy-on-write (contrairement à LVM, ce qui impose une utilisation temporaire des snaps et une impossibilité de les chainer sans effondrer les perfs)
- le dump des datasets (zfs send/receive) pour transférer le contenu d'un dataset vers un autre dataset zfs (distant ou local) ou vers un fichier. Possibilité d'utiliser le send incrémentale entre 2 snapshots.
- le scrubbing, vérification de l'intégrité des DATAs présentent dans le zpool.
- à vous de voir pour les autres fonctionnalités.....
Par contre, gros "mauvais point", pas de possibilité d'étendre des RAIDZ (1,2 ou 3). Il faut aggréger un nouveau RAIDZ (et de taille identique si possible, pour ne pas créer d'asymétrie au niveau IOs). Contrairement à WAFL qui a son RAID DP basé sur le RAID 4 (+1 parité supplémentaire), qui lui utilisant des disques dédiés aux paritées, permet l'ajout de disque à une grappe RAID.
Voilà, en espérant avoir éclaircit la lanterne de certains sur ce FS qui mériterait vraiment une utilisation "large" tellement il offre de possibilités.