Concernant BTRFS, je suis totalement d'accord avec toi, je ne vois pas pourquoi on utilise le terme COW… Effectivement, BTRFS-ZFS-WAFL lors de snapshot ne font que figer les blocks en fesant pointer le snapshot sur ces derniers, ce qui implique d'écrire les nouvelles données ailleurs. Ce n'est donc pas de la Copy-On-Write (comme on l'entend du moins pour LVM), car il n'y a pas d'opération de copy lors d'une écriture… Si quelqu'un sait pourquoi on utilise COW pour BTRFS, je suis preneur.
Encore une fois, ne pas confondre la partie block et la partie fichier.
Si le périphérique de block reçoit une data erronée qui peut avoir l'air correcte du point de vue de ses algos de correction, il écrira une donnée corrompue du point de vue fs mais correct du point de vue block.
Je dirais que le scrubbing et le checksum ne sont pas à envisager pour du disque unitaire, mais plutôt pour des RAID (Z1,Z2,Z3).
Il faut que l'intégralité des stripes+parité soient correctement écrites pour qu'une donnée soit valide. Chaque disque n'est capable de corriger que son stripe, si un disque dysfonctionne et n'écrit pas le stripe correctement mais indique un ACK sur cette dernière, au dessus, le FS (ou le RAID Hard ou Soft) pensera que tout s'est bien passé, hors une corruption a eu lieu (une corruption silencieuse). Le seul moyen de corriger sera d'effectuer un scrubbing et/ou d'effectuer une vérification du checksum de la donnée.
J'avoue que c'est ceinture-bretelle-caleçon blindée et que pour l'instant, même avec des arrêts élec sauvages, mon zpool n'a jamais indiqué d'erreur (réparée ou non). Mais encore une fois, tout dépend de l'importance des données stockées sur le zpool…
ZFS est orienté vers un stockage cohérent et sûr de la data. Mais effectivement, on peut se passer totalement de faire des scrubbings. On peut faire la même chose avec sa voiture ;-), tout dépend de ce qu'on peut se permettre de risquer !!!
Effectivement, ext* ne fragmente pas….. du moins dans de bonnes conditions ;-).
Il faut un minimum d'espace pour que de nouvelles données soient écrites non-fragmentées.
La diff entre ext* et les FS MS (du moins les FAT*) vient de leur logique lors de l'écriture.
Logique MS (pour NTFS je n'ai pas l'info, mais vu la présence de defrag, je pense que c'est encore le cas !), j'ai un fichier à écrire, je prends les premiers blocks dispos et j'écris… du coup, je découpe pour remplir les trous
Logique ext*, je cherche le premier espace assez grand pour contenir ma donnée entière (c'est plus long, mais mieux dans le long terme). Biensûr, cette approche est possible tant qu'il reste assez d'espace pour y mettre la donnée entière en un bloc.
La plupart des FS (si ce n'est tous) n'aiment pas le manque d'espace, ZFS et WAFL ne font pas exception. Netapp indique clairement qu'il ne faut pas dépasser 90%-95% de remplissage des aggrégats sinon: dégradation de perf et nécessité de réallocation (et là, quand t'es en prod, tu sers les fesses pour ne pas créer trop de latence dans les applicatifs qui se servent de la baie)
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).
Que tu t'en cognes…. pourquoi pas ;-)…. mais, tout dépend de ta préoccupation et de ton besoin.
Si tu reprends mon post de réponse quelques lignes plus haut, j'explique "très sommairement" les avantages de ce FS-ng (je dis ng, car BTRFS-ZFS-WAFL ne sont pas "que" des FS, ils gèrent la couche stockage entière.
Maintenant, clairement, si c'est pour une machine perso… tu n'y verras pas d'intérêt. Par contre, pour de la virtu, pour du serveur de fichier, pour du docker…. là, ça sera très intéressant.
On peut prendre NTFS en exemple… tous les windowsiens ont un FS qui dans les dernières versions gèrent: la compression, le snapshot, la dédup…. simplement, ils n'en ont pas l'utilité… mais quand il s'agit d'une utilisation serveur, là, ces fonctionnalités deviennent importantes.
Quand tu modifies une donnée, la plupart du temps, les FS réécrivent par dessus l'ancienne donnée (à part BTRFS, il me semble, car il est aussi un FS-ng), ça évite la fragmentation d'ailleurs.
Petite précision, ZFS gérant aussi la couche RAID (WAFL aussi d'ailleurs), ce comportement est encore plus important pour éviter les corruptions silencieuses.
Je connais un peu, car je suis admin stockage ;-). J'ai plus souvent l'habitude de travailler sur des baies (surtout NetAPP) que sur des FS de serveur. Mais je monte aussi des baies de stockage à partir de serveurs (quand on voit ce qu'est un contrôleur NetAPP, c'est de toute manière là même chose !).
J'utilise ZFS à titre perso et pro, c'est quasi systématiquement mon choix quand il s'agit d'être sûr de la pérennité de la donnée. J'ai bien cru un moment à BTRFS dont les fonctionnalités sont très proches (du moins, tente de raccrocher les wagons avec ZFS, développé par ORACLE à l'origine d'ailleurs), mais ce FS me laisse un peu sur ma faim. L'histoire du balance à effectuer manuellement dans certains cas où ton système t'indique que tu as encore de la place mais qu'il te remonte qu'il n'y a plus de d'espace sur le device quand tu tentes une écriture, m'a plutôt échaudé (du moins pour ce qui concernerait une éventuelle mise en prod).
Pour ce qui est des docs, je ne vais pas trop pouvoir t'aider, car j'ai plutôt glâner de l'infos à droite à gauche du fait de mon métier. Tu peux déjà chercher des comparos de FS sur wikipédia, ça résume les différences et spécificités des différents FS.
il y a aussi Aaron Toponce https://pthree.org/category/zfs/ qui donne pas mal d'infos sur l'utilisation de ZFS.
Contrairement à ce que tu penses, Debian (ou les linux) ne proposent pas que du extX par défaut, tu as un très grand nombre de FS dispos (peut⁻être pas à l'installation): XFS, reiserfs 3.5, reiserfs 4, btrfs… et beaucoup d'autres.
Plus classiquement, tu choisis un FS selon le besoin que tu en as:
- Snapshot: XFS,ext4, resiserfs… couplé à LVM… ou alors ZFS, BTRFS
- Dédup: euh…. bah ZFS !! sinon, il y a les opendedup et autres couches, mais je ne suis pas convaincu.
- Backup distant de FS (ou réplication asynchrone): ZFS, BTRFS…. éventuellement LVM + FS
- compression: ZFS, BTRFS……
- Quantité de fichiers sur les FS: XFS et reiserfs semblent bien disposés à ce genre de contrainte, ZFS aussi.
Pas besoin de "taper dans le noyau", du moins dans un premier temps. Quand tu en arrives au tuning kernel, c'est que tu est déjà aller bien loin dans l'utilisation du FS ;-)
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é à 1.
Je me réponds à moi-même. Il semble que BTRFS-ZFS-WAFL soient des FS utilisant la fonction ROW (Redirect on Write), LVM est COW (Copy on write), pour le snapshot. Ouf, sinon, il faut que je change de métier !
http://ram.kossboss.com/zfs-btrfs-are-row-not-cow-redirect-on-write-not-copy-on-write/
[^] # Re: Zfs vs BTRFS
Posté par marsupilamies . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 1.
Concernant BTRFS, je suis totalement d'accord avec toi, je ne vois pas pourquoi on utilise le terme COW… Effectivement, BTRFS-ZFS-WAFL lors de snapshot ne font que figer les blocks en fesant pointer le snapshot sur ces derniers, ce qui implique d'écrire les nouvelles données ailleurs. Ce n'est donc pas de la Copy-On-Write (comme on l'entend du moins pour LVM), car il n'y a pas d'opération de copy lors d'une écriture… Si quelqu'un sait pourquoi on utilise COW pour BTRFS, je suis preneur.
[^] # Re: Zfs vs BTRFS
Posté par marsupilamies . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 5.
Encore une fois, ne pas confondre la partie block et la partie fichier.
Si le périphérique de block reçoit une data erronée qui peut avoir l'air correcte du point de vue de ses algos de correction, il écrira une donnée corrompue du point de vue fs mais correct du point de vue block.
Je dirais que le scrubbing et le checksum ne sont pas à envisager pour du disque unitaire, mais plutôt pour des RAID (Z1,Z2,Z3).
Il faut que l'intégralité des stripes+parité soient correctement écrites pour qu'une donnée soit valide. Chaque disque n'est capable de corriger que son stripe, si un disque dysfonctionne et n'écrit pas le stripe correctement mais indique un ACK sur cette dernière, au dessus, le FS (ou le RAID Hard ou Soft) pensera que tout s'est bien passé, hors une corruption a eu lieu (une corruption silencieuse). Le seul moyen de corriger sera d'effectuer un scrubbing et/ou d'effectuer une vérification du checksum de la donnée.
J'avoue que c'est ceinture-bretelle-caleçon blindée et que pour l'instant, même avec des arrêts élec sauvages, mon zpool n'a jamais indiqué d'erreur (réparée ou non). Mais encore une fois, tout dépend de l'importance des données stockées sur le zpool…
ZFS est orienté vers un stockage cohérent et sûr de la data. Mais effectivement, on peut se passer totalement de faire des scrubbings. On peut faire la même chose avec sa voiture ;-), tout dépend de ce qu'on peut se permettre de risquer !!!
[^] # Re: Zfs vs BTRFS
Posté par marsupilamies . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 1.
Effectivement, ext* ne fragmente pas….. du moins dans de bonnes conditions ;-).
Il faut un minimum d'espace pour que de nouvelles données soient écrites non-fragmentées.
La diff entre ext* et les FS MS (du moins les FAT*) vient de leur logique lors de l'écriture.
Logique MS (pour NTFS je n'ai pas l'info, mais vu la présence de defrag, je pense que c'est encore le cas !), j'ai un fichier à écrire, je prends les premiers blocks dispos et j'écris… du coup, je découpe pour remplir les trous
Logique ext*, je cherche le premier espace assez grand pour contenir ma donnée entière (c'est plus long, mais mieux dans le long terme). Biensûr, cette approche est possible tant qu'il reste assez d'espace pour y mettre la donnée entière en un bloc.
La plupart des FS (si ce n'est tous) n'aiment pas le manque d'espace, ZFS et WAFL ne font pas exception. Netapp indique clairement qu'il ne faut pas dépasser 90%-95% de remplissage des aggrégats sinon: dégradation de perf et nécessité de réallocation (et là, quand t'es en prod, tu sers les fesses pour ne pas créer trop de latence dans les applicatifs qui se servent de la baie)
[^] # 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).
[^] # Re: Zfs vs BTRFS
Posté par marsupilamies . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 5.
Que tu t'en cognes…. pourquoi pas ;-)…. mais, tout dépend de ta préoccupation et de ton besoin.
Si tu reprends mon post de réponse quelques lignes plus haut, j'explique "très sommairement" les avantages de ce FS-ng (je dis ng, car BTRFS-ZFS-WAFL ne sont pas "que" des FS, ils gèrent la couche stockage entière.
Maintenant, clairement, si c'est pour une machine perso… tu n'y verras pas d'intérêt. Par contre, pour de la virtu, pour du serveur de fichier, pour du docker…. là, ça sera très intéressant.
On peut prendre NTFS en exemple… tous les windowsiens ont un FS qui dans les dernières versions gèrent: la compression, le snapshot, la dédup…. simplement, ils n'en ont pas l'utilité… mais quand il s'agit d'une utilisation serveur, là, ces fonctionnalités deviennent importantes.
[^] # Re: Zfs vs BTRFS
Posté par marsupilamies . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 9.
Quand tu modifies une donnée, la plupart du temps, les FS réécrivent par dessus l'ancienne donnée (à part BTRFS, il me semble, car il est aussi un FS-ng), ça évite la fragmentation d'ailleurs.
Petite précision, ZFS gérant aussi la couche RAID (WAFL aussi d'ailleurs), ce comportement est encore plus important pour éviter les corruptions silencieuses.
Je connais un peu, car je suis admin stockage ;-). J'ai plus souvent l'habitude de travailler sur des baies (surtout NetAPP) que sur des FS de serveur. Mais je monte aussi des baies de stockage à partir de serveurs (quand on voit ce qu'est un contrôleur NetAPP, c'est de toute manière là même chose !).
J'utilise ZFS à titre perso et pro, c'est quasi systématiquement mon choix quand il s'agit d'être sûr de la pérennité de la donnée. J'ai bien cru un moment à BTRFS dont les fonctionnalités sont très proches (du moins, tente de raccrocher les wagons avec ZFS, développé par ORACLE à l'origine d'ailleurs), mais ce FS me laisse un peu sur ma faim. L'histoire du balance à effectuer manuellement dans certains cas où ton système t'indique que tu as encore de la place mais qu'il te remonte qu'il n'y a plus de d'espace sur le device quand tu tentes une écriture, m'a plutôt échaudé (du moins pour ce qui concernerait une éventuelle mise en prod).
Pour ce qui est des docs, je ne vais pas trop pouvoir t'aider, car j'ai plutôt glâner de l'infos à droite à gauche du fait de mon métier. Tu peux déjà chercher des comparos de FS sur wikipédia, ça résume les différences et spécificités des différents FS.
il y a aussi Aaron Toponce https://pthree.org/category/zfs/ qui donne pas mal d'infos sur l'utilisation de ZFS.
Contrairement à ce que tu penses, Debian (ou les linux) ne proposent pas que du extX par défaut, tu as un très grand nombre de FS dispos (peut⁻être pas à l'installation): XFS, reiserfs 3.5, reiserfs 4, btrfs… et beaucoup d'autres.
Plus classiquement, tu choisis un FS selon le besoin que tu en as:
- Snapshot: XFS,ext4, resiserfs… couplé à LVM… ou alors ZFS, BTRFS
- Dédup: euh…. bah ZFS !! sinon, il y a les opendedup et autres couches, mais je ne suis pas convaincu.
- Backup distant de FS (ou réplication asynchrone): ZFS, BTRFS…. éventuellement LVM + FS
- compression: ZFS, BTRFS……
- Quantité de fichiers sur les FS: XFS et reiserfs semblent bien disposés à ce genre de contrainte, ZFS aussi.
Pas besoin de "taper dans le noyau", du moins dans un premier temps. Quand tu en arrives au tuning kernel, c'est que tu est déjà aller bien loin dans l'utilisation du FS ;-)
[^] # 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.