Bonjour,
Pour commencer, voici le contexte (la demande du client): Mettre en place un serveur Linux pour le stockage des données collaboratives entre autres. Ces données devront être accessibles depuis Mac, Windows et Linux, avec des ACL (groupes/utilisateurs). Il y a environ 300Go de données (pdf, doc, xls, ...) pour le moment.
J'ai installé une Debian 8.2.0 et le partage se fera en smb avec l'utilisation de Samba.
L'association de Samba sur un système de fichier en Btrfs me semble intéressante notamment avec les fonctionnalités apportées : shadow copy, copy-on-write, compression à la volée, défragmentation en ligne. Mais j'ai trouvé des discussions (plus ou moins ancienne) disant que ce système de fichier n'est pas abouti et présentant pas mal de problèmes. Ce qui amène les interrogations suivantes : Utilisez-vous Btrfs en test ou production ? Quelles sont vos impressions après plusieurs semaines/mois d'utilisations ?
Merci. -- Albéric
Lu,
J’utilise Btrfs dans le cadre d’une plate-forme de backup mais aussi pour stocker des boites mails ça fait bien son taff, après tu peux jouer sur le system de compression qui utilise plus ou moins de cpu, mais dans tout les cas prévoir une machine avec un peu de puissance cpu et de bon disque.
-- Cordialement, Corentin BONNETON contact@titin.fr
Salut,
Pareil ici, on l'utilise sur à peu près tous nos systèmes de backup. C'est pratique pour les snapshots (de toutes façons l'ancien système basé sur rsync et --link-dest se terminait plus avant le début des backups suivants)… On a plusieurs systèmes, de quelques dizaines de Giga à plus d'un To, ça tourne pas mal. Sur les version 3.15 à 3.16.1 du noyau il y avait un deadlock assez méchant qui freezait le système (référencé ici https://btrfs.wiki.kernel.org/index.php/Gotchas) sur des rsync de disques de machines virtuelles (le workaround était de désactiver le CoW sur lesdites images ce qui a pour effet de bord de désactiver la compression). Je pense que c'est pas mal stable pour une utilisation dans les cas « nominaux » (compression et snapshots compris), après pour le RAID intégré la dernière fois que j'ai regardé c'était prendre plus de risques qu'autre chose (genre tu pouvais re-add un disque dirty sans que ça le gène).
Cordialement,
Le 12/12/2015 19:11, BONNETON Corentin a écrit :
Merci pour vos retours.
@Denis : J'avoue ne pas connaître plus ZFS que Btrfs. As-tu de l’expérience avec ZFS sur Debian ?
-- Albéric
Le 12 décembre 2015 à 20:49, Denis Fondras xxsag@ledeuns.net a écrit :
@Denis : J'avoue ne pas connaître plus ZFS que Btrfs. As-tu de l’expérience avec ZFS sur Debian ?
Je l'utilise depuis plus de 2 ans mais pas dans les mêmes conditions que toi. J'ai principalement des installations où il y'a très peu de fichiers mais de plusieurs dizaines de Go. Je n'ai qu'une seule installation avec des milliers de petits fichiers pour ~100Go. Je n'ai aucun soucis pour le moment (je touche du bois :o). J'avais testé Btrfs il y'a 3 ans et c'était catastrophique en terme de stabilité et je n'ai donc pas voulu retenter l'expérience lorsque j'ai eu besoin d'un FS moderne.
btrfs, c'était encore très intense il y a 3 ans, avec de nombreuses fonctionnalités "en cours de dev" (comprendre : complétement bug), ou "qui vient de sortir" (comprendre: à utiliser si tu es joueur) Aujourd'hui, si tu regardes la liste des features (https://btrfs.wiki.kernel.org/index.php/Main_Page#Features), tu constates que les fonctionnalités "in development, or planned", sont beaucoup moins centrales que précedement (cf "le support du raid", "la gestion d'erreur du raid6" etc) Du fait, les pull requests sont moins impressionnantes que précédement, ce qui signifie que le fs est en cours de maturation
Pour répondre à la question originale (butterfs utilisable en production ?), chacun a son opinion de la stabilité, mais je pense qu'aujourd'hui, avec un kernel récent, c'est tout à fait utilisable, bien plus qu'il y a de 3ans ! On 13/12/2015 09:09, Denis Fondras wrote:
J’approuve a chaque Maj de kernel ou mineur, brtfs deviens de plus en plus stable.
Effectivement il y a 3 ans même 1ans c’était la misère mais en tout cas pour mon cas sous jessie j’ai des partitions btrfs de 10 To ça tourne sans problème :)
-- Cordialement, Corentin BONNETON contact@titin.fr
Le 12/12/2015 18:57, Alberic ALEXANDRE a écrit :
Pour les problèmes connus / à éviter :
Bonjour,
J'ai testé BTRFS il y a environ 3 ans, et le produit était déjà présenté comme "très stable". Pourtant, j'ai remarqué que les performances en lectures/écritures s'effondraient littéralement avec le temps (on parle de division par cinq des perfs au bout de 6 mois si mes souvenirs sont bons).
Depuis, j'ai accordé ma confiance à ZFS On Linux : le système de fichiers en lui même est plus qu'éprouvé (sur Solaris), et l'implémentation Linux est de plus en plus robuste (je la juge en tout cas "production ready". Creuse donc dans cette voie, car tu vas y retrouver toutes les features de BTRFS que tu cherches ;)
Olivier
Le 12 décembre 2015 à 23:24, Ruben Alves gadept@gmail.com a écrit :
Bonjour
Ce que j'ai compris du workshop btrfs lors de la Susecon, btrfs n'est qu'une implémentation libre de zfs, qui ne le serait pas, lui. Btrfs a été créé par un ancien mainteneur zfs, passé chez Suse. Btrfs est donc maintenant inclus au Kernel, contrairement à zfs. Et ceci dit, Suse en recommande l'usage pour le système alors qu'ils recommandent xfs sur une BD.
À bientôt,
Le sam. 12 déc. 2015 23:29, Olivier Doucet webmaster@ajeux.com a écrit :
Le 2015/12/13 07:26, Olivier Duquesne (DaffyDuke) a écrit :
FOUTAISES !⁽¹⁾ https://www.wikiwand.com/fr/Common_Development_and_Distribution_License
¹ : https://www.wikiwand.com/fr/Business_loto
Bonjour,
De ce que j'ai suivi, ZFS est distribué sous une licence opensource (CDDL) incompatible avec la GPL, ce qui explique pourquoi il n'est pas directement disponible dans le noyau. Il est quand même utilisable via une implémentation FUSE. Concernant BTRFS, il s'agirait plutôt d'un nouveau système de fichier fortement inspiré de ZFS plutôt que d'une ré-implémentation de ce dernier.
My two cents, Jonathan
On 12/13/2015 07:26 AM, Olivier Duquesne (DaffyDuke) wrote:
Bonjour,
Le 14 décembre 2015 à 09:01, Jonathan Tremesaygues < jonathan.tremesaygues@menta.fr> a écrit :
Attention : l'implémentation FUSE a des performances très mauvaises ! Je parlais de l'implémentation Kernel avec SPL+ZFS connue sous le nom de ZfsOnLinux. Les perfs sont bien meilleures là dessus.
Concernant BTRFS, il s'agirait plutôt d'un nouveau système de fichier
fortement inspiré de ZFS plutôt que d'une ré-implémentation de ce dernier.
Absolument : BTRFS a fait d'autres choix de stratégies d'implémentation, et dixit un collègue "on se rend compte avec le temps que c'était pas forcément la meilleure idée du monde".
Après, comme dans tout le monde Open Source, rien ne vaut le bon vieux test. Pour ma part, je te conseillerais surtout de laisser tourner des lectures+écritures+réécritures intensives sur deux semaines, et voir si les performances tombent avec le temps.
Olivier
Le Sat, Dec 12, 2015 at 06:57:43PM +0100, Alberic ALEXANDRE [alberic.alexandre@gmail.com] a écrit: [...]
Utilisez-vous Btrfs en test ou production ?
Non.
Quelles sont vos impressions après plusieurs semaines/mois d'utilisations ?
Les "no space left on device" incompréhensibles (genre sur un "rm" ...) le rendent à mon sens inutilisable en vrai. (je te laisse fouiller ton moteur de recherche préféré)
Quelques corruptions aussi quand on avait fait des tests, mais ça, ça devait être des problèmes de jeunesse qui ont surement été résolus depuis.
Bonjour,
Le 14 décembre 2015 à 09:20, Dominique Rousseau d.rousseau@nnx.com a écrit :
même expérience ici. En plus des checks espace disque et inodes, il faut vérifier l'espace prit par les snapshots qui sont automatiquement ajouté au moindre apt-get ou autre programme, mais jamais purgé.
Pour ma part j'ai revert vers ext4 et XFS, qui ont peut-être un chouilla moins de perf, de features, de je ne sais quoi, mais qui fonctionnent conventionnellement.
Hello,
(prise en vol du thread)
Le 14 décembre 2015 à 09:20, Dominique Rousseau < d.rousseau@nnx.com > a écrit :
Alors j'ai jamais utilisé btrfs personnellement car j'utilise Linux moins souvent que FreeBSD (encore que...).
De mon coté "no space left on device" pour un rm est totalement compréhensible sur un FS COW based (comme ZFS par exemple), ceci dit, avoir des FS plein raz la tronche surtout avec du COW c'est limite suicidaire. Une règle : si disk free < 20% => alors danger.
Pourquoi ?
Le fs va chercher de la place et s'il ne trouve pas, va fragmenter a mort le fichier, qui vas baisser en perf et bref... => le mur (sans compter la baisse de performance).
Ceci dit pour de petites machines (ou vm) qui n'ont pas besoin de "sécurité des données" : UFS (freebsd !) ou XFS sous Linux (moins casses pieds que ext* avec des environements virtualisé aux IO disques pouvant varier).
Xavier
Bref, c'est pas utilisable en prod.
Le 14 décembre 2015 à 14:12, Olivier B. frsag.list@daevel.fr a écrit :
De mon côté,
zfs en production pour du filer, du serveur de backup, du serveur web, ... RAS avec zfsonlinux ( et pas l'implémentation Fuse, qui comme dit précédemment à des perfs catastrophiques ).
Btrfs, testé en production => pas encore sec ( notamment combiné avec un kernel grsec, tu te retrouves avec des failures size_overflow detecté par PaX et boom, le fichier ou repertoire accédé n'est plus dispo ).
Je l'utilise cependant au quotidien sur mon laptop, et pour du desktop/workstation c'est pas mal du tout.
Si besoin de plus d'infos ou de retour perfs, n'hésitez pas !
On 12/14/2015 07:23 AM, Greg wrote:
On 12/14/2015 08:31 PM, Tristan Mahé wrote:
J'en avais aussi, et depuis le commit 81e26429b7a36f0c75de3ab42754256720c0a159 de grsec il n'y en a plus de mon côté.
Je l'utilise cependant au quotidien sur mon laptop, et pour du desktop/workstation c'est pas mal du tout.
Idem pour moi.
Si besoin de plus d'infos ou de retour perfs, n'hésitez pas !
On 12/14/2015 06:54 PM, Leo Gaspard wrote:
le size_overflow dans try_merge_map n'est pas encore corrigé, mais tu n'auras le problème que lors d'un load assez violent pendant assez longtemps. ( fais donc un update world sur une gentoo, et en même temps joue avec des containers docker en backend devicemapper, tu verra apparaitre très vite le problème ).
-
Alberic ALEXANDRE -
Bernard BELLE -
BONNETON Corentin -
Corentin Bonneton
-
Denis Fondras -
Dominique Rousseau -
frsag＠jack.fr.eu.org -
Greg -
Guillaume Friloux -
Jean-Yves LENHOF -
Jonathan Tremesaygues -
Leo Gaspard -
Olivier B. -
Olivier Doucet -
Olivier Duquesne (DaffyDuke) -
Ruben Alves -
Sébastien Le Ray -
Tristan Mahé -
Xavier Beaudouin