Journal Btrfs ne serait plus le futur

Posté par (page perso) . Licence CC by-sa
Tags :
49
2
août
2017

2008 : Butter FS (Btrfs) semble le système de fichiers du futur.
[source LinuxFr.org !]

2012 : il avance à grands pas [toujours sur LinuxFr.org].

2017 : dans sa note de publication Red Hat Enterprise Linux (RHEL) 7.4
Red Hat déclare que Btrfs n’est plus de la partie pour RHEL :

« The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux. »

En effet, Bbtrfs était déjà en version expérimentale dans RHEL 6, mais avait été temporairement écarté.
Maintenant, il semble que ce soit écarté, pour de bon.


Sources :

  • # Juste une histoire de ressources de développement

    Posté par . Évalué à 10 (+22/-0).

    Je suis l'auteur de la dépêche de 2012 et, en tant qu'utilisateur de btrfs, je dois bien admettre que son développement est frustrant tant il est lent. Pour autant, il n'est pas à l'arrêt. La mailing list des développeurs en atteste (en réagissant notamment à l'annonce de Redhat) : ça travaille toujours dessus. Peu d'améliorations visibles, beaucoup de polissage et de stabilisation. Il n'y a pas de mystère : si ça avance peu c'est que les hp, Redhat, Oracle, Facebook (l'employeur de Chris Mason, un des développeurs principaux) n'investissent pas assez dedans. S'ils mettaient chacun ne serait-ce que deux devs à temps plein, ça pourrait booster l'évolution de btrfs.

    Quand je lis ces dépêches sur un développeur qui, d'un seul coup, se met en tête d'écrire un système de gestion de fichiers avec Copy on Write en partant de rien, ça me fait marrer. Même en étant un génie, cette personne ne va pas arriver à la stabilité d'un vénérable ZFS (qui a 7 ou 8 ans de plus que btrfs et un peu plus de développeurs actifs) en un jour.

    Si je devais résumer les conseils d'utilisation heureuse de btrfs, je dirais :

    • Avoir un noyau aussi récent que possible
    • Avoir les outils btrfs les plus récents possibles
    • Ne pas laisser le nombre de snapshots s'envoler. Quelques centaines, ça reste gérable. Au delà ça rame de trop.
    • Éviter le RAID 5/6 (dernièrement réécrit en partie) mais le RAID 1, 0, 1+0, c'est bien stable.
    • Éviter la compression transparente (j'ai déjà été mordu… :) )
    • Les bases de données, les images de VM peuvent se fragmenter très vite sur un volume btrfs. L'option autodefrag y remédie en partie… mais pour les meilleures perfs brutes, mieux vaut ici partir sur de l'xfs ou de l'ext4.
    • La gestion des quotas par volume est aussi dans la sphère du "peu testé". À éviter.
    • Planifier des "scrub" (relecture et vérification des checksums des blocs) réguliers
    • Garder un œil sur les statistiques disque de btrfs, qui peuvent indiquer qu'un disque commence à exhiber des erreurs. En RAID1 ou 5, il est alors temps de remplacer le disque défectueux avant d'expérimenter des pertes de données

    Les snapshots, même si ça ne sert pas très souvent, c'est quand même bien pratique… et la possibilité de transmettre (comme ZFS) ces derniers entre machines (entiers ou deltas entre 2 snaps), c'est aussi bien commode.

    Bref, ne jetons pas le bébé avec l'eau du bain.

    • [^] # Re: Juste une histoire de ressources de développement

      Posté par . Évalué à 2 (+0/-0).

      Les snapshots, même si ça ne sert pas très souvent, c'est quand même bien pratique… et la possibilité de transmettre (comme ZFS) ces derniers entre machines (entiers ou deltas entre 2 snaps), c'est aussi bien commode.

      C'est possible ?
      cela mérite d'être étudié merci pour l'info

      • [^] # Re: Juste une histoire de ressources de développement

        Posté par . Évalué à 4 (+4/-0).

        Je me sers des snapshots BTRFS pour faire des sauvegardes incrémentales avec un coût ultra faible et des scripts hyper simples, sur mon NAS (PC de récup). Combiné avec les scrub hebdomadaires ça a un coût de stockage faible et une fiabilité raisonnable une fois combiné avec un RAID 1 (mirroring) et des sauvegardes offline mensuelles.
        Mais ça n'est clairement pas le genre d'installation que je ferais en entreprise, par contre…

        • [^] # Re: Juste une histoire de ressources de développement

          Posté par . Évalué à 1 (+2/-2).

          Je fais exactement pareil, mais quand j'ai décrit cette approche dans mon dernier journal :
          https://linuxfr.org/users/saintgermain/journaux/gestion-de-versions-et-sauvegarde-de-donnees
          Certains personnes ont hurlé à l'hérésie car ces snapshots ne sont pas considéré comme des sauvegardes.

          • [^] # Re: Juste une histoire de ressources de développement

            Posté par . Évalué à 6 (+4/-0).

            Nan le hurlement à l'hérésie concernait le fait de considérer qu'une copie locale était une vraie sauvegarde. Ici on parle de faire des snapshots zfs/btrfs qui sont envoyés automatiquement sur un stockage distant.

            • [^] # Re: Juste une histoire de ressources de développement

              Posté par . Évalué à -1 (+0/-2).

              Je me sers des snapshots BTRFS pour faire des sauvegardes incrémentales […] sur mon NAS. Combiné avec […] et des sauvegardes offline mensuelles.

              Ah j'ai peut-être mal interprété en effet. Est-ce qu'il fait des snapshots de son PC personnel et qu'il les envoient sur son NAS après (et cela devient alors des sauvegardes). Ou bien est-ce qu'il fait des snapshots de son NAS ?

          • [^] # Re: Juste une histoire de ressources de développement

            Posté par . Évalué à 1 (+1/-0).

            Mon système est à peu près similaire, sauf que les sauvegardes distantes en question sont hors ligne. Ce sont des disques durs chiffrés qui sont ailleurs que chez moi, non branchés. Quand je veux mettre à jour les sauvegardes distantes, je ramène le disque, et je lance mon script qui fait:
            - mountage du disque, luksOpen et tout le toutim
            - effacement complet du contenu du disque
            - copie des fichiers avec un rsync tout simple (c'est pour la reprise en cas de pépin)
            - scrub de toute la partition ntfs
            - si le scrub est ok, la sauvegarde est supposée bonne, luksClose et umount, puis je débranche.
            - si je souhaitais valider une sauvegarde, suffit de brancher le disque et de faire un scrub

            Mon système a deux failles:
            - les snapshots ne sont pas en lecture seule. Faut faire hyper gaffe. Mais en relisant de la doc, je viens de découvrir que ça existe en btrfs et que je ne le savais pas, btrfs subvolume snapshot -r
            - la sauvegarde distante ne marche que si ma sauvegarde courante est bonne. si j'avais un soucis avec la sauvegarde locale, ça foire tout.

            Ça part aussi du principe que la clé de chiffrement est sur un autre média que tout ce que j'ai cité. Je l'ai en 3 copies, une sur le serveur local de sauvegarde, deux sur des clés usb chiffrées avec veracrypt.

            • [^] # Re: Juste une histoire de ressources de développement

              Posté par . Évalué à 1 (+0/-0).

              Mais du coup je n'ai pas compris, tu fais des snapshots de ton NAS sur ton NAS, ou bien tu fais des snapshots de ton PC personnel et tu envoies ensuite les snapshots sur ton NAS ?

              Je ne parle pas de la recopie des snapshots de ton NAS sur le disque dur externe, ça j'ai bien compris.

              • [^] # Re: Juste une histoire de ressources de développement

                Posté par . Évalué à 0 (+0/-0). Dernière modification le 03/08/17 à 19:59.

                J'ai un dossier current qui contient un sous-dossier pour chaque appareil et chaque groupement de fichiers à sauvegarder. Les fichiers y sont déposés, suivant les dossiers par des scripts avec rsync ou des applications mobiles ou à la main, bref tout moyen capable de déposer un fichier dans un dossier.
                C'est sur ce dossier current que les snapshots de subvolume sont effectués, sachant que cette partition en RAID 1 ne sert qu'à ça.

                • [^] # Re: Juste une histoire de ressources de développement

                  Posté par . Évalué à 1 (+0/-0).

                  Ok tu fais donc à peu près comme moi et je vois que l'on à peu près les mêmes besoins.

                  D'après ce que je comprends, tu vas donc avoir aussi les mêmes problèmes avec ton approche :

                  • est-ce que ton NAS ne te sert que de support de sauvegarde ? Autrement il te faudra aussi sauvegarder les données qui ne sont que sur ton NAS (c'était la principale difficulté de mon journal).
                  • si tu chiffres tes disques externes, je suppose que tu chiffres aussi ton NAS (autrement quelqu'un volant ton NAS aurait accès à toutes les données de toutes tes machines) ? Si oui il y a pas mal de problèmes associés
                  • tu sauvegardes une partition Btrfs sur une partition NTFS, du coup si je comprends bien tu perds tout le bénéfice de la déduplication des données (2 snapshots incrémentaux seront sauvegardés comme 2 ensembles indépendants).
                  • tu fais énormément confiance à ton RAID1 si je comprends bien ? Si jamais il y a un problème qui n'est pas détecté/corrigé par ton RAID1, le problème sera recopié sur ton disque externe ?

                  Je vois d'autres soucis potentiels, mais j'aimerais d'abord confirmer les points que j'ai donnés.

                  • [^] # Re: Juste une histoire de ressources de développement

                    Posté par (page perso) . Évalué à 2 (+0/-0).

                    si tu chiffres tes disques externes, je suppose que tu chiffres aussi ton NAS (autrement quelqu'un volant ton NAS aurait accès à toutes les données de toutes tes machines) ? Si oui il y a pas mal de problèmes associés

                    Perso, je conserve une copie de mes sauvegardes sur un disque dur chiffré que je stocke au boulot. Ce disque est chiffré : il a beau être dans un tiroir avec des affaires personnelles, et étiqueté comme étant un disque personnel, je n'ai aucune assurance qu'il ne sera pas accédé par un tiers. Je dirais même que la probabilité, sans être élevée, est loin d'être négligeable.
                    En tout cas, bien plus élevée que celle de me faire voler mon NAS chez moi.
                    Du coup, je chiffre mes sauvegardes externes tout comme mes portables, mais aucunement les médiums qui reste chez moi.

                    Jusqu'à maintenant.

                    Le mois dernier, j'ai une collègue qui s'est fait cambriolée. Tout a été volé : le portable et les disques durs externes.
                    Les données originales comme les sauvegardes ont disparues, et sont potentiellement accessibles par n'importe qui.

                    J'avoue que je commence à me demander comment réagir face à cela aussi.

                    • [^] # Re: Juste une histoire de ressources de développement

                      Posté par . Évalué à 1 (+0/-0).

                      La probabilité de se faire cambrioler me semble quand même assez forte. Pour mon cas personnel, je connais vraiment beaucoup de gens à qui cela est arrivé.

                      En tout cas j'ai bien plus de gens ayant subi un cambriolage, que de gens ayant subi un crash disque brutal entraînant la perte de toutes les données (mais c'est sans doute que c'est un sujet moins populaire).

                      Si tu n'as pas de RAID, avec un système de fichier exotique comme Btrfs, c'est pourtant relativement simple de chiffrer.

                    • [^] # Re: Juste une histoire de ressources de développement

                      Posté par (page perso) . Évalué à 3 (+1/-0).

                      Je dois être nul parce que je ne comprends pas le problème de chiffrer son NAS chez soi. OK s'il reboot tout seul pendant qu'on est en vacances on est niqué pour taper la passphrase, mais ça me parait un risque acceptable, plutôt que réduire quasiment à néant l'intérêt du chiffrement (surtout dans le cas d'un fixe, pour un portable admettons) en copiant les données en clair à côté…

                      • [^] # Re: Juste une histoire de ressources de développement

                        Posté par . Évalué à 1 (+0/-0).

                        Si tu as un seul disque en ext4, le chiffrement ne pose pas de problèmes particuliers. À part le fait qu'en cas de soucis, c'est plus difficile de débrancher le disque et de le lire sur un autre ordinateur.

                        Avec du RAID en Btrfs, c'est quand même plus sportif mais pas impossible. Mais si cela se trouve, c'est ce qu'il fait, donc attendons sa réponse.

                        Pour l'anecdote, la plupart des gens à qui j'en parle me prennent pour un paranoïaque quand je dis que je chiffre mon NAS (pourtant leur iPhone est chiffré par défaut…). Il ne faut pas perdre de vue que les problèmes de vie privée, cela passe complètement au-dessus de la tête de la grande majorité des gens.

                        • [^] # Re: Juste une histoire de ressources de développement

                          Posté par (page perso) . Évalué à 3 (+1/-0).

                          Pour ma part je fais du RAID, mais le RAID de Linux, avec donc des partitions du type Linux RAID point de vue des disques, et ensuite le volume luks est en ext4, et c'était aucunement sportif (j'ai déjà remplacé sans problème des disques qui ont claqué, etc).

                          C'est pas pour faire le RH-fanboy mais j'ai un peu l'impression que dans toutes les conversations autour de ce journal, le problème commun est btrfs.

                          • [^] # Re: Juste une histoire de ressources de développement

                            Posté par . Évalué à 1 (+0/-0).

                            C'est pas pour faire le RH-fanboy mais j'ai un peu l'impression que dans toutes les conversations autour de ce journal, le problème commun est btrfs.

                            Euh c'est pas un peu normal dans un journal parlant de Btrfs que l'on parle surtout des problèmes rencontrés autour de Btrfs ? ;-)
                            Mais de tête quelques soucis que j'ai eus (qui n'ont rien à voir avec Btrfs) :

                            • n'avoir à entrer qu'une seule fois le mot de passe pour tous les disques, cela n'a pas été évident.
                            • avec du RAID, il faut se poser la question de mettre le chiffrement au dessus ou en dessous du FS, les performances ne sont pas les mêmes (chiffrer plusieurs fois la donnée vs chiffrer une seule fois).
                            • problème au démontage : https://github.com/systemd/systemd/issues/1620

                            Et sinon le chiffrement avec du RAID c'est clairement moins facile qu'avec un seul disque, ne serait-ce que parce que la plupart des tutoriaux/ressources sur le sujet abordent le cas le plus courant : un seul disque. Donc c'est plus difficile de trouver des infos/retours.

                            Faire proprement du RAID, ce n'est pas donné à tout le monde. Et faire proprement du chiffrement, ce n'est pas non plus très accessible. Alors faire proprement du RAID + chiffrement, je doute que ce soit facile et accessible pour tout le monde, d'où mon adjectif pas du tout scientifique de « sportif ».

                            • [^] # Re: Juste une histoire de ressources de développement

                              Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 04/08/17 à 14:12.

                              Euh c'est pas un peu normal dans un journal parlant de Btrfs que l'on parle surtout des problèmes rencontrés autour de Btrfs ? ;-)

                              Je dis ça dans le sens où "ça marche mal" (y compris une fonctionnalité non spécifique comme le RAID) c'est souvent "à cause de btrfs" (encore une fois, je vois pas en quoi le RAID classique est casse-gueule alors que visiblement avec btrfs c'est limite plus dangereux que pas de RAID).

                              Et sinon le chiffrement avec du RAID c'est clairement moins facile qu'avec un seul disque

                              Je l'ai mis en place par dessus mon RAID logiciel, le tout en 3 clics, avec Anaconda à l'installation de ma machine, je ne tape qu'une fois la passphrase au démarrage et elle sert pour déchiffrer le RAID et le SSD système chiffré de son côté également, sans avoir fait quoi que ce soit à la main pour que ce soit le cas. Vraiment je ne vois pas en quoi "le RAID chiffré c'est dur" par contre je commence à voir "n'utilisez surtout pas btrfs".

                              • [^] # Re: Juste une histoire de ressources de développement

                                Posté par . Évalué à 1 (+0/-0).

                                Je dis ça dans le sens où "ça marche mal" (y compris une fonctionnalité non spécifique comme le RAID) c'est souvent "à cause de btrfs"

                                Peut-être que tu ne sais pas que Btrfs gère lui-même le RAID ?
                                Et que donc dans ce cas si le RAID ne marche pas bien avec Btrfs, c'est forcément de fait la faute de Btrfs ?

                                encore une fois, je vois pas en quoi le RAID classique est casse-gueule

                                Le RAID classique n'est peut-être pas casse-gueule, mais le RAID avec Btrfs l'est forcément, vu que Btrfs lui-même est un peu casse-gueule (et que c'est Btrfs qui gère le RAID).

                                btrfs c'est limite plus dangereux que pas de RAID

                                Btrfs c'est dangereux tout court si tu ne fais pas attention. Voir mon message tout en bas qui critique qui présente Btrfs sous son plus beau jour.

                                Et sinon le chiffrement avec du RAID c'est clairement moins facile qu'avec un seul disque

                                Je l'ai mis en place par dessus mon RAID logiciel, le tout en 3 clics, avec Anaconda à l'installation de ma machine, je ne tape qu'une fois la passphrase au démarrage et elle sert pour déchiffrer le RAID et le SSD système chiffré de son côté également, sans avoir fait quoi que ce soit à la main pour que ce soit le cas. Vraiment je ne vois pas en quoi "le RAID chiffré c'est dur" par contre je commence à voir "n'utilisez surtout pas btrfs".

                                Non ton argumentation est trop généraliste : « dans mon cas personnel, j'ai juste cliqué et ça marche, donc c'est facile ».
                                Tout le monde n'a pas les mêmes conditions que toi.

                                Avec le même argument, on pourrait dire « linux c'est facile, j'ai inséré une galette Ubuntu, j'ai cliqué sur Install et roule ma poule cela a marché, je ne comprends pas pourquoi certains disent que installer et utiliser linux c'est difficile ».

                                Pour mon cas perso, j'ai fait le choix d'avoir le chiffrement en dessous du FS (et donc du RAID), ce qui complique un peu les choses.
                                J'aurais pu choisir un répertoire encfs directement dans mon FS et cela aurait été beaucoup plus facile.

                                Tout dépend de ses contraintes et de ses choix.

                                • [^] # Re: Juste une histoire de ressources de développement

                                  Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 04/08/17 à 16:10.

                                  Peut-être que tu ne sais pas que Btrfs gère lui-même le RAID ?

                                  Si si je l'ai bien compris, et justement c'est mon point, que j'ai visiblement exposé trop subtilement, alors je recommence en plus simpliste : btrfs ça craint et RH a raison de s'en éloigner.

                                  Non ton argumentation est trop généraliste : « dans mon cas personnel, j'ai juste cliqué et ça marche, donc c'est facile ».
                                  Tout le monde n'a pas les mêmes conditions que toi.

                                  Avec le même argument, on pourrait dire « linux c'est facile, j'ai inséré une galette Ubuntu, j'ai cliqué sur Install et roule ma poule cela a marché, je ne comprends pas pourquoi certains disent que installer et utiliser linux c'est difficile ».

                                  Bah, si. C'est peut-être compliqué si tu veux écrire toi-même à coup de dd les entêtes de tes partitions RAID ou que sais-je, mais à moins d'aimer se compliquer la vie pour rien (ou d'avoir des conditions très spécifiques, auquel cas je te renvoie ton "dans mon cas ça marche" en ajoutant un "pas"), non dans l'absolu ce n'est pass compliqué.

                                  Pour mon cas perso, j'ai fait le choix d'avoir le chiffrement en dessous du FS (et donc du RAID), ce qui complique un peu les choses.

                                  Eh bah relis bien, moi aussi, c'est mon volume chiffré (créé sur le RAID logique) qui est en ext4, le chiffrement est également sous mon FS. Et comme le RAID est sous le FS je vois pas comment "sous le FS" implique "sous le RAID", y a un gros problème d'implications logiques qui ne compilent pas, là. D'ailleurs précisément c'est FS > chiffrement > RAID. C'est pas en mélangeant tout que ça va devenir crédible ton histoire…

                                  • [^] # Re: Juste une histoire de ressources de développement

                                    Posté par . Évalué à 1 (+0/-0).

                                    Peut-être que tu ne sais pas que Btrfs gère lui-même le RAID ?

                                    Si si je l'ai bien compris,

                                    Pour mon cas perso, j'ai fait le choix d'avoir le chiffrement en dessous du FS (et donc du RAID), ce qui complique un peu les choses.

                                    Eh bah relis bien, moi aussi, c'est mon volume chiffré (créé sur le RAID logique) qui est en ext4, le chiffrement est également sous mon FS. Et comme le RAID est sous le FS je vois pas comment "sous le FS" implique "sous le RAID", y a un gros problème d'implications logiques qui ne compilent pas, là. D'ailleurs précisément c'est FS > chiffrement > RAID. C'est pas en mélangeant tout que ça va devenir crédible ton histoire…

                                    Ben c'est pourtant simple : Btrfs gère le RAID, donc dans le cas de Btrfs le RAID est au dessus du FS. Donc dans mon cas, "sous le FS" implique forcément "sous le RAID".

                                    Donc pour moi chiffrement < Btrfs < RAID.

                                    En théorie (j'ai pas essayé), je peux enlever le RAID d'une commande en ligne et je me retrouve juste avec chiffrement < Btrfs.

                      • [^] # Re: Juste une histoire de ressources de développement

                        Posté par (page perso) . Évalué à 3 (+1/-0).

                        OK s'il reboot tout seul pendant qu'on est en vacances on est niqué pour taper la passphrase

                        Ou alors tu t’y connectes en ssh : https://packages.debian.org/stretch/dropbear-initramfs

                    • [^] # Re: Juste une histoire de ressources de développement

                      Posté par . Évalué à 0 (+0/-0).

                      Comme tout désastre possible, il faut analyser la probabilité que ça se produise, et l'impact si ça se produit. Dans mon cas, c'est hautement improbable (je ne détaillerai pas pourquoi ici) qu'on soit cambriolés et qu'on vole un PC moche vieux de 10 ans/NAS
                      L'analyse de l'impact, je ne détaillerai pas non plus ici, mais c'est fait aussi.

                      Malgré tout, oui, chiffrer la sauvegarde locale online est en cours de réflexion malgré tout. J'ai surtout mis la priorité à court terme sur le chiffrement des PC portables, les mobiles, les sauvegardes offline hors site, les clés USB et puis les rares données sur mon nextcloud.

                      J'améliore graduellement la sécurité de mes données ; ça prend du temps.

                  • [^] # Re: Juste une histoire de ressources de développement

                    Posté par . Évalué à 0 (+0/-0).

                    est-ce que ton NAS ne te sert que de support de sauvegarde ? Autrement il te faudra aussi sauvegarder les données qui ne sont que sur ton NAS (c'était la principale difficulté de mon journal).

                    Non, mais les autres données présentes dessus sont considérées comme sacrifiables. Et en plus elles sont sur des disques différents de ceux dédiés aux sauvegardes.
                    Je sauvegarde le /etc du NAS, mais je saurais honnêtement le reconstruire, ça prendrait quelques heures.

                    si tu chiffres tes disques externes, je suppose que tu chiffres aussi ton NAS (autrement quelqu'un volant ton NAS aurait accès à toutes les données de toutes tes machines) ? Si oui il y a pas mal de problèmes associés

                    Non, mais j'en suis conscient et c'est prévu comme évolution imminente. Le NAS étant un PC de récup moche et vieux de 10 ans (+ d'autres facteurs), ça n'est encore pas une inquiétude majeure.

                    tu sauvegardes une partition Btrfs sur une partition NTFS, du coup si je comprends bien tu perds tout le bénéfice de la déduplication des données (2 snapshots incrémentaux seront sauvegardés comme 2 ensembles indépendants).

                    J'ai du louper un peu l'explication. Les disques offline sont en btrfs, mais une partition qui n'est pas une copie de la sauvegarde current, c'est juste fait avec un rsync après effacement. Je ne sauvegarde pas les snapshots pour des raisons de budget disque, mais ça va sans doute changer sous peu, dès que j'aurais le budget. Tout comme le nombre de disques de sauvegarde offline que je vais augmenter progressivement.
                    Je considère aussi comme acceptable de perdre un mois de données en cas de désastre combiné "source de données cassée"/"raid 1 du NAS cassé".

                    tu fais énormément confiance à ton RAID1 si je comprends bien ? Si jamais il y a un problème qui n'est pas détecté/corrigé par ton RAID1, le problème sera recopié sur ton disque externe ?

                    C'est un gros point faible, en effet. Il manque un système pour valider que le contenu du current du NAS est identique aux sources de données des sauvegardes. Ça résoudrait en partie le problème, même si rien ne garantit que la source n'a pas été corrompue entre temps (déjà subi :( ).
                    Pour les sauvegardes faites avec du rsync, je pourrais forcer une fois par mois (voire à chaque fois) le mode --checksum. Pour les autres sources de données, c'est du cas par cas.

                    L'autre point qui manque, c'est régulièrement de faire des tests de scénarios de désastre pour découvrir des faiblesses et documenter les restaurations, ça reste le meilleur moyen.
                    J'ai récemment écrasé partiellement (involontairement, c'était génial) le début d'un des disques du raid et ça a été très formateur.

                    Tous les process de sauvegarde du monde ne valent rien tant qu'on a pas validé rigoureusement que toutes les pièces du mécanisme fonctionnent avec des tests.

                    • [^] # Re: Juste une histoire de ressources de développement

                      Posté par . Évalué à 0 (+0/-0).

                      J'ai du louper un peu l'explication. Les disques offline sont en btrfs, mais une partition qui n'est pas une copie de la sauvegarde current, c'est juste fait avec un rsync après effacement

                      Oups, c'est pas clair non plus. Ce que je voulais dire c'est que je ne copie que les fichiers de la sauvegarde courante, pas la structure de la partition btrfs avec les subvolumes des précédentes.

        • [^] # Re: Juste une histoire de ressources de développement

          Posté par . Évalué à 2 (+0/-0).

          Bon cela dépend du type d'application qui sont sur le serveur mais sinon …
          pourquoi ne pas rejouer les snapshost régulièrement ? et tester si l'applicatif fonctionnent ?

          Dommage car ce genre de solution coûte généralement cher quand il est pris en charge au niveau de la baie de stockage.
          de plus dans certains cas de figure, comme les bases de données, la réplication au niveau bloc me semble difficile à réaliser.

    • [^] # Re: Juste une histoire de ressources de développement

      Posté par . Évalué à 1 (+1/-0).

      Quel est exactement le problème avec la compression sur btrfs ?
      J'ai juste rencontré des soucis d'usage de CPU avec l'algo zlib, sur des machines faiblardes, mais pas de soucis en lzo au bout de 1 an et demi sur mon modeste serveur de backup en ligne.

      Pour les remarques précédentes, le BTRFS n'a pas comme cible la haute performance, tout comme le ZFS. Le cas d'utilisation actuel théorique est plutôt la fiabilité et la possibilité de valider l'état des fichiers (bitrot et tout ça, surtout quand on a de mauvais contrôleurs et disques), ou les snapshots.

      Au sujet de Red Hat, ça reste l'une des distro les plus conservatrices qui soient. Le fait que BTRFS ne soit pas juste une nouvelle version d'un système de fichier existant ne doit pas trop aider à son acceptation, d'autant plus que j'entends fréquemment des histoires de scénarios catastrophes à son sujet (jamais rencontrés personnellement sur mes mini prods). Et la compression ou les snapshots, ça reste des problèmes qu'on peut résoudre en balançant bêtement plus d'espace disque. Ça ne laisse donc pas beaucoup d'avantages sur les autres fs malgré cette liste de features.

      • [^] # Re: Juste une histoire de ressources de développement

        Posté par . Évalué à 1 (+1/-1).

        Le cas d'utilisation actuel théorique est plutôt la fiabilité et la possibilité de valider l'état des fichiers (bitrot et tout ça, surtout quand on a de mauvais contrôleurs et disques), ou les snapshots.

        Oui et notons que Btrfs en RAID1 permet de détecter et corriger le bitrot. Certaines personnes ici me juraient que ce n'était pas possible dans mon dernier journal.

      • [^] # Re: Juste une histoire de ressources de développement

        Posté par . Évalué à 3 (+2/-0).

        À une époque, la compression finissait en deadlock sur des fichiers de quelques GiB si on modifiait des blocs au milieu du fichier.
        Globalement dès que tu passes en utilisation intensive ça commence à piquer. Pour l'utiliser en backups sur de gros volumes, les hung tasks et le freeze sont pas si rares que ça.
        Perso je suis en train de tout basculer sur ZFS après 4 années à me dire « ça ira mieux à la prochaine release »

        • [^] # Re: Juste une histoire de ressources de développement

          Posté par . Évalué à 0 (+0/-0).

          Ok, merci !

        • [^] # Re: Juste une histoire de ressources de développement

          Posté par . Évalué à 1 (+0/-0).

          À une époque, la compression finissait en deadlock sur des fichiers de quelques GiB si on modifiait des blocs au milieu du fichier.

          Hormis les VMs, est-ce que tu as d'autres exemples de modifications de fichiers de ce type ?

          Globalement dès que tu passes en utilisation intensive ça commence à piquer. Pour l'utiliser en backups sur de gros volumes, les hung tasks et le freeze sont pas si rares que ça.

          Dans le cas d'une utilisation pro ou perso ?

          Merci !

          • [^] # Re: Juste une histoire de ressources de développement

            Posté par . Évalué à 2 (+1/-0).

            Hormis les VMs, est-ce que tu as d'autres exemples de modifications de fichiers de ce type ?

            C'étaient effectivement des ISOs de VM dans le cas que j'ai en tête

            Dans le cas d'une utilisation pro ou perso ?

            Utilisation pro, on avait besoin de pouvoir faire des snapshots pour la rotation des backups…

            Tiens encore à l'instant :

            INFO: task kworker/u16:3:126 blocked for more than 120 seconds.
            Not tainted 4.9.0-0.bpo.3-amd64 #1
            Workqueue: btrfs-freespace-write btrfs_freespace_write_helper [btrfs]
            Call Trace:
            [<ffffffffa8c0089d>] ? __schedule+0x23d/0x6d0
            [<ffffffffa8c00d62>] ? schedule+0x32/0x80
            [<ffffffffc055ee16>] ? btrfs_tree_lock+0x126/0x220 [btrfs]
            [<ffffffffa86bb830>] ? wake_up_atomic_t+0x30/0x30
            [<ffffffffc04f8b4d>] ? btrfs_search_slot+0x6bd/0x9e0 [btrfs]
            [<ffffffffc0538458>] ? btrfs_mark_extent_written+0xa8/0xb70 [btrfs]
            [<ffffffffc054123e>] ? lock_extent_bits+0x7e/0x240 [btrfs]
            [<ffffffffa87e1a69>] ? kmem_cache_alloc+0xb9/0x200
            [<ffffffffc051e552>] ? join_transaction.isra.14+0x22/0x3f0 [btrfs]
            [<ffffffffc0520fbd>] ? start_transaction+0x9d/0x4a0 [btrfs]
            [<ffffffffc052a9c1>] ? btrfs_finish_ordered_io+0x441/0x690 [btrfs]
            [<ffffffffa862ecc5>] ? sched_clock+0x5/0x10
            [<ffffffffc0554b56>] ? normal_work_helper+0xc6/0x2d0 [btrfs]

    • [^] # Re: Juste une histoire de ressources de développement

      Posté par (page perso) . Évalué à 5 (+3/-0).

      Quand je lis ces dépêches sur un développeur qui, d'un seul coup, se met en tête d'écrire un système de gestion de fichiers avec Copy on Write en partant de rien, ça me fait marrer. Même en étant un génie, cette personne ne va pas arriver à la stabilité d'un vénérable ZFS (qui a 7 ou 8 ans de plus que btrfs et un peu plus de développeurs actifs) en un jour.

      Et Hammer ?
      :-)

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Juste une histoire de ressources de développement

      Posté par . Évalué à 1 (+3/-4).

      Les bases de données, les images de VM peuvent se fragmenter très vite sur un volume btrfs. L'option autodefrag y remédie en partie… mais pour les meilleures perfs brutes, mieux vaut ici partir sur de l'xfs ou de l'ext4.

      Je trouve cela particulierement redhibitoire aujourd'hui. Parceque a vus de nez les BD et les VM sur une machine linux cela doit toucher … 100% des utilisateurs.

      • [^] # Re: Juste une histoire de ressources de développement

        Posté par (page perso) . Évalué à 2 (+0/-0).

        Tu oublies qu'il suffit de les mettre sur une partition dédiée.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Juste une histoire de ressources de développement

          Posté par . Évalué à 2 (+1/-1).

          Ce qui est un peu contraignant et oblige a savoir tes besoins de VM au moment de l'installation. Je ne parle meme pas du fait que un des avantages, en theorie, des FS modernes c'est justement de se passer des partitions cree a l'installation et de travailler avec des volumes. Enfin d'apres ce que j'en ai compris. Alors peut etre que si tu mets tes VM sur un volume particulier le probleme de fragmentation n'existe plus mais bon sous ext4 ce probleme n'existe pas (que je sache). La communaute linux c'est assez moque de FAT et la defragmentations…

          • [^] # Re: Juste une histoire de ressources de développement

            Posté par (page perso) . Évalué à 4 (+2/-0).

            Il sera toujours contraignant d'avoir un système optimisé.
            Mais si tu fais des VM et des BD tu t'y connais assez pour manipuler des volumes logiques avec LVM pour les étendre au besoin.
            Quant à l'utilisation quotidienne elle demeure transparente grâce aux points de montage. Maintenant il est clair qu'on parle d'utilisation intensive, tu n'auras aucun problèmes avec des VM ou des BD en tests pour qq jours.
            Enfin, c'est la fragmentation des fichiers de VM et de BD qui est en cause, pas celle du système de fichier qui fragmentera de toute façon.

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

            • [^] # Re: Juste une histoire de ressources de développement

              Posté par . Évalué à 2 (+0/-0).

              Enfin, c'est la fragmentation des fichiers de VM et de BD qui est en cause, pas celle du système de fichier qui fragmentera de toute façon.

              Et la fragmentation des VM et des BD c'est pas lie au systeme?

              • [^] # Re: Juste une histoire de ressources de développement

                Posté par (page perso) . Évalué à 3 (+1/-0).

                Tss, tss, ne joue pas sur les mots, bien sûr que c'est lié au système de fichier! Mais ça ne concerne que ces types de fichiers pour lesquels les extents sont peut-être mal réservés, pas les autres fichiers. Et aussi, quand on emploie des disques SSD la fragmentation du système de fichier n'a pas grand sens (au moins pour l'instant), or c'est ce qu'on fait si on cherche la performance sur les VM et les BD.

                "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Juste une histoire de ressources de développement

        Posté par . Évalué à 6 (+7/-2).

        Je trouve cela particulierement redhibitoire aujourd'hui. Parceque a vus de nez les BD et les VM sur une machine linux cela doit toucher … 100% des utilisateurs.

        Il faudrait penser à ne pas exagérer. Il y a des gens (dont moi) qui utilisent linux sur leur machine personnelle et on a pas tous forcément besoin de grosse base de données ou de machines virtuelles.

        • [^] # Re: Juste une histoire de ressources de développement

          Posté par . Évalué à 1 (+1/-2).

          Il y a de plus en plus de logiciels installe par defaut qui vont te creer une BD qui va grandir est arriver a une taille consequente. Je pense a toutes les technos semantique avec baloo/akonadi/tracker.

          • [^] # Re: Juste une histoire de ressources de développement

            Posté par . Évalué à 3 (+2/-0).

            Ici on parle de base de données qui deviennent suffisamment grosses pour ralentir Btrfs significativement.
            Les bases sqlite de quelques centaines de Mo, je ne pense pas que cela ralentisse Btrfs.

            Tu as sans doute des cas particuliers de gens qui arrivent à avoir des dizaines de Go dans leur base de données sqlite avec Firefox, Tracker ou autres. Mais on parlait de 100% des utilisateurs de linux donc on ne prend pas en compte les cas particuliers

            • [^] # Re: Juste une histoire de ressources de développement

              Posté par (page perso) . Évalué à 3 (+1/-0).

              Tu as sans doute des cas particuliers de gens qui arrivent à avoir des dizaines de Go dans leur base de données sqlite avec Firefox, Tracker ou autres.

              d'ailleurs le système est déjà fortement ralentit dans ce cas

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

            • [^] # Re: Juste une histoire de ressources de développement

              Posté par . Évalué à 0 (+0/-2).

              Ici on parle de base de données qui deviennent suffisamment grosses pour ralentir Btrfs significativement.

              C'est bien pour cela que j'ai parle des BD semantique qui peuvent, assez rapidement, grossir a plusieurs Gigas (ce n'est pas pour rien que j'ai decide de ne plus me servir de ce genre d'outil, c'est pratique mais avec un DD de laptop cela peut facilement devenir un peu … lourd.

              Mais on parlait de 100% des utilisateurs de linux donc on ne prend pas en compte les cas particuliers

              Il est vrai que j'avais pas pense au telephone mais bon en dehors de 1 cas extremement particulier (joola?), je pense que l'on peut dire que la presence de btrfs sur ce genre de matos est … nul. Donc on retrouve BTRFS ou? Sur le desktop, les serveurs et dans les HPC et tu veux me faire croire que dans ces deux las tu as beaucoup d'utilisateur n'ayant:

              • ni VM
              • ni BD un peu consequente

              J'ai un "leger" doute. Je suis pret a parier que la grande majorite des utilisateurs linux
              desktop ont des VMs et sur les deux autres il y a forcement des BD.

      • [^] # Re: Juste une histoire de ressources de développement

        Posté par . Évalué à 5 (+3/-0). Dernière modification le 03/08/17 à 14:46.

        les BD et les VM sur une machine linux cela doit toucher … 100% des utilisateurs.

        Ou pas. Les VMs sont des outils à l'usage très particulier, quand même. Je doute que des VMs soient installées sur les téléphones…
        Quant aux bases de données… c'est beaucoup utilisé pour de petites quantités de données, aussi (configuration, par exemple), et je doute qu'un FS puisse poser de réels problèmes de perfs sur des bases de données qui ne dépassent pas le GiO.

        Mais bon, dans l'absolu, tu as raison, les BdD sont utilisées par tout le monde, puisque la plupart des navigateurs web en utilisent (config, signets, historique…), sans parler du /etc/passwd.

        • [^] # Re: Juste une histoire de ressources de développement

          Posté par . Évalué à 0 (+0/-2).

          Je doute que des VMs soient installées sur les téléphones…

          Je doute que btrfs soit installe sur un autre tel que joola (et meme la je ne suis pas sur).

          • [^] # Re: Juste une histoire de ressources de développement

            Posté par . Évalué à 7 (+6/-1).

            Sauf que tu ne parlais pas de 100% des utilisateurs de BTRFS sur Linux, mais de 100% des utilisateurs Linux.
            Et clairement, des utilisateurs Linux n'ont aucun intérêt pour BTRFS, les VMs ou les BdD lourdes. On peut parler des téléphones android, des routeurs, des caméra IP, des machines de bureau pas utilisées par des dév ou admin… et j'en oublie fatalement.

            • [^] # Re: Juste une histoire de ressources de développement

              Posté par . Évalué à 5 (+4/-1).

              Apple sest fait chier à déployer son nouveau fs (du meme tonneau que zfs et btrfs) sur qq centaines de millions de téléphones et iPads, je me dit qu’ils doivent y voir un intérêt pour faire une migration aussi risquée.

              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: Juste une histoire de ressources de développement

              Posté par . Évalué à 0 (+0/-2).

              Donc tu penses que dans linux n'a pas besoin de systeme de fichier moderne et adapte a des besoin future? Interessant…

              • [^] # Re: Juste une histoire de ressources de développement

                Posté par . Évalué à 3 (+1/-0).

                Donc tu penses que dans linux n'a pas besoin de systeme de fichier moderne et adapte a des besoin future? Interessant…

                Donc tu penses que tout le monde à besoin de VM? Intéressant…

                • [^] # Re: Juste une histoire de ressources de développement

                  Posté par . Évalué à 1 (+0/-1). Dernière modification le 04/08/17 à 10:49.

                  Il me semble mais je peux me tromper naturellement, cela m'arrive souvent, que ext4 n'est pas forcement un FS fait pour les SSD, il me semble aussi qu'il a une taille maximale. Enfin il me semble.

                  D'ailleurs c'est rigolo si les FS actuels sont si bien pourquoi est ce qu'il y autant de boulot (et d'argent) mis pour developper un successeur. Cela doit etre pour le plaisir de jeter l'argent par les fenetres…

                  • [^] # Re: Juste une histoire de ressources de développement

                    Posté par (page perso) . Évalué à 4 (+2/-0).

                    ext4 n'est pas forcement un FS fait pour les SSD

                    Je ne connais pas de systèmes de fichiers généralistes taillés pour ces périphériques. Le ext4 est suffisant pour cela.

                    il me semble aussi qu'il a une taille maximale

                    Tout système de fichier a des limites quelque part pour la taille du système de fichier, pour le nombre de fichiers, etc.

                    Le ext4 n'a pas la limite la plus basse du secteur, mais avant que ton ordinateur personnel arrive à cette limite, il faudra du temps (si on y arrive un jour).

                    D'ailleurs c'est rigolo si les FS actuels sont si bien pourquoi est ce qu'il y autant de boulot (et d'argent) mis pour developper un successeur. Cela doit etre pour le plaisir de jeter l'argent par les fenetres…

                    Il y a des systèmes de fichiers très variés, mais tous ne sont pas destinés à un usage général. Beaucoup sont spécialisés. Tu ne verras pas squashfs comme système de fichier pour tes données par exemple. Rient ne dit que btrfs est réellement pertinent pour tout le monde (de même que ext4 en fait) mais probablement pour des usages spécifiques.

                    • [^] # Re: Juste une histoire de ressources de développement

                      Posté par . Évalué à 2 (+0/-0). Dernière modification le 06/08/17 à 00:30.

                      https://www.maketecheasier.com/best-linux-filesystem-for-ssd/

                      Ext4 is a satisfactory choice for solid-state drives with filesystem journaling disabled, and a decent choice for most users, but it should not be the first choice.

                      Je parle du futur mais c'est bien de ne rien prevoir et d'etre reactif et non pro-actif ce n'est pas comme si la recherche sur les systemes de stockage n'etait pas un des domaines les plus actifs.

                      Il y a des systèmes de fichiers très variés, mais tous ne sont pas destinés à un usage général. Beaucoup sont spécialisés. Tu ne verras pas squashfs comme système de fichier pour tes données par exemple.

                      Et?

                      Rient ne dit que btrfs est réellement pertinent pour tout le monde (de même que ext4 en fait) mais probablement pour des usages spécifiques.

                      Oui en effet rien ne dit mais je ne defend pas specialement btrfs, je dis juste que c'est bien joli tout cela, ext4 est super stable mais bon le futur ne lui appartient surement pas.

                  • [^] # Re: Juste une histoire de ressources de développement

                    Posté par . Évalué à 3 (+1/-0).

                    ext4 n'est pas forcement un FS fait pour les SSD,

                    Pourquoi?

                    D'ailleurs c'est rigolo si les FS actuels sont si bien pourquoi est ce qu'il y autant de boulot (et d'argent) mis pour developper un successeur.

                    Peut-être parce que les FS actuels ne suffisent pas pour des usages précis? Un particulier n'aura pas nécessairement besoin de dedup, mais pour des gros serveurs ça permets probablement de réduire de façon non-négligeable l'occupation des disques.

                    C'est surtout ça la teneur de mon propos original: je ne dis pas que BTRFS est inutile, je dis que ce FS ne réponds pas nécessairement aux besoins d'utilisateur non spécialistes. Ou peut-être qu'il y répond mais qu'il n'apporte réellement rien de plus qui serait utilisé par le type d'utilisateur en question.

                    Puisque tu sembles considérer que les spécificités de BTRFS ont un intérêt pour tous les utilisateurs, expliques-moi sa plus-value pour quelqu'un qui se limite à ouvrir un navigateur web et une suite bureautique?

                    • [^] # Re: Juste une histoire de ressources de développement

                      Posté par . Évalué à 9 (+7/-0).

                      mais pour des gros serveurs ça permets probablement de réduire de façon non-négligeable l'occupation des disques.

                      Pour des applis mobile dont la plupart utilisent en général les meme librairies aussi. Dedup 5-50Mo par applis installée, ça te fait vite gagner quelques Go de disque.
                      Sinon y’a le cow.
                      Et le chiffrement.
                      Et l’intégrité des données.
                      Et la compression à la volée.

                      Écoute, je sais pas quoi te dire. Alors, non, tata Michu va pas faire grand chose de btrfs en soi. Mais les mecs qui écrivent des applis qu’elle utilise, eux, vont probablement être content de savoir que les features listées au dessus sont dispo. Et tata Michu va probablement pas remarquer que quand elle copie des gros fichiers, c’est instantane, mais ça lui changera un peu la vie en pratique.

                      J’ai du mal à comprendre comment on peut argumenter contre des trucs pareil sur un site pareil. Après, y’a bien des mecs pour t’expliquer que sysv init, ça roxxor, alors pourquoi pas. Et ces très ironique de voir ça, vu comment les linuxiens avaient tendance à se la peter avec ext2 face a fat/ntfs pendant longtemps. Maintenant que Linux est à la ramasse niveau fs, bizarrement, les fs deviennent vachement moins important.

                      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                      • [^] # Re: Juste une histoire de ressources de développement

                        Posté par . Évalué à 1 (+1/-2).

                        Pour des applis mobile dont la plupart utilisent en général les meme librairies aussi.

                        Tiens, on pratique l'édition de lien statique dans le mobile? Ou alors on est revenu au mode Windows et on réinvente le DLHell?

                        • [^] # Re: Juste une histoire de ressources de développement

                          Posté par . Évalué à 6 (+4/-0).

                          Tiens, on pratique l'édition de lien statique dans le mobile?

                          Oui, depuis toujours. Les libs système sont bien évidemment dynamiques et distribuées avec l’os.
                          Les libs tierces, elles sont bundlées avec l’appli. Ce qui est le modèle que toutes les plateformes avec un tant soit peu de succès suivent depuis toujours, soit dit en passant. Et aussi une pratique standard côté serveur (cf le shading de jar, ou encore ce que fait go).

                          iOS fait des liens dynamiques avec les libs du bundle soit dit en passant ce qui est un compromis assez décen, pour android, c’est des jar, donc un peu plus compliqué, mais grosso merdo le meme concept.

                          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                        • [^] # Re: Juste une histoire de ressources de développement

                          Posté par . Évalué à 2 (+1/-1). Dernière modification le 04/08/17 à 16:48.

                          Windows et on réinvente le DLHell?

                          Le DLLHell n'existe plus depuis l'avènement de plusieurs choses :
                          - Windows 98 (1998), qui a introduit le "Side-by-Side assembly"
                          - Windows XP (2001) et son "registration-free COM"
                          - L'usage de permissions sur les dossiers systèmes (Windows NT, 1993)
                          - Le .NET Framework (2001)

                          Et c'est pas moi qui le dit, c'est wikipedia :
                          https://en.wikipedia.org/wiki/DLL_Hell#Solutions

                          Il va falloir se mettre à jour.

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                          • [^] # Re: Juste une histoire de ressources de développement

                            Posté par . Évalué à -1 (+1/-4).

                            Ah oui? Marrant, je jurerai que j'ai un collègue qui a récemment eu des conflits de DLL la semaine dernière…

                            • [^] # Re: Juste une histoire de ressources de développement

                              Posté par (page perso) . Évalué à 4 (+2/-0).

                              Il n'a vraiment pas de bol ton collègue. Je n'ai plus eu de soucis avec les DLL depuis au moins 10 ans, peut-être 15 (pas certain).
                              Et pourtant mon job au quotidien est d'administrer/maintenir/dépanner les systèmes informatiques bureautiques de nos clients.

                              • [^] # Re: Juste une histoire de ressources de développement

                                Posté par . Évalué à 2 (+0/-0).

                                Le nôtre (à moi et mon collègue, du moins pour le moment), c'est de développer une surcouche à des logiciels dits de PLM. En l'occurrence, un quickfix de l'éditeur (parce que prochain fix propre dans 3 mois) à généré ce problème.

                                Par bureautique, tu veux bien dire juste déployer et maintenir un brouteur, une suite FoobarOffice et un MUA? Pas de plugins non empaquetés à déployer à la mimine? Par de Framework capilotractés contre lesquels te battre (non, parce que bon, Microsoft l'air de rien fait un taf plus que respectable, malgré ce que je peux parfois en dire: faut le faire, maintenir un OS avec autant de rétrocompat pendant si longtemps)?

                      • [^] # Re: Juste une histoire de ressources de développement

                        Posté par . Évalué à 2 (+0/-0).

                        Je soupconne que le fait que Albert_ et groumle defendent ce genre de chose explique beaucoup de chose (et je m'inquiete d'etre d'accord avec toi sur le sujet :) ).

                        Parler de btrfs dans un journal btrfs semble etre non pertinnent pour certaines personnes… je comprend absolument rien a la logique de certaines personnes….

                    • [^] # Re: Juste une histoire de ressources de développement

                      Posté par . Évalué à 2 (+0/-0).

                      Pourquoi?

                      Extended 4 is not designed with SSDs in mind. It is true that it has file system trim support (a critical SSD feature), but outside of that the filesystem was never designed for this use case. Why? It uses a filesystem journal. This means that the filesystem is constantly writing logs down and informing the system of every single change. This can quickly wear out the limited write-space on an SSD running Linux.

                      Ext4 is a satisfactory choice for solid-state drives with filesystem journaling disabled, and a decent choice for most users, but it should not be the first choice.

                      Et ext4 sans journal c'est pas forcement le but non?

                  • [^] # Re: Juste une histoire de ressources de développement

                    Posté par . Évalué à 2 (+1/-1). Dernière modification le 04/08/17 à 15:17.

                    ext c'est très bien pour tout le monde jusqu'au jour où on se rendu compte qu'on a oublié de désactiver le fsck automatique au bout de x mount/jours et qu'on va devoir taper quelques heures d'attente alors qu'on pensait juste faire un reboot de quelques secondes/minutes.

        • [^] # Re: Juste une histoire de ressources de développement

          Posté par (page perso) . Évalué à 4 (+1/-0).

          Je doute que des VMs soient installées sur les téléphones…

          Pourtant, il y des gens qui bossent là dessus. L'intérêt étant de pouvoir avoir des contextes bien isolé (par exemple, un contexte pro et un contexte perso).

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Juste une histoire de ressources de développement

            Posté par . Évalué à 3 (+1/-0).

            Donc, pour avoir des contextes bien isolés, tu es obligé de faire des VMs? D'émuler plutôt que compartimenter? Ca me semble un peu lourd, non?

            Ceci étant dit, je peux voir l'intérêt oui, pour du public spécialisé.

            • [^] # Re: Juste une histoire de ressources de développement

              Posté par (page perso) . Évalué à 4 (+1/-0).

              Donc, pour avoir des contextes bien isolés, tu es obligé de faire des VMs?

              Non, mais c'est un moyen assez "simple" pour le faire.

              D'émuler plutôt que compartimenter?

              On n'est plus dans l'émulation pour les VM actuelles. Et puis, l'intérêt, c'est qu'on pourrait imaginer des systèmes complètement différents. Genre un Firefox OS Ubuntu Phone Windows Mobile pour le boulot et un Plasma mobile pour le perso.

              Ca me semble un peu lourd, non?

              Difficile de juger vu qu'il n'y a pas encore de produit. Mais quand on voit l'overhead des VM sur x86, on peut se dire que ça vaut la peine.

              Ceci étant dit, je peux voir l'intérêt oui, pour du public spécialisé.

              Personnellement, si je pouvais déjà isolé facilement les applis de merde de mes mails/contact, je serais content.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Juste une histoire de ressources de développement

      Posté par . Évalué à 2 (+1/-0).

      Je tourne en RAID1 Btrfs aussi, et je n'ai eu aucun soucis particulier dans le cadre d'un usage domestique.

      Notons cependant que le RAID 1 avec « N-way mirroring » (N > 2) n'est toujours pas possible avec Btrfs.
      Du coup il faut faire très attention lorsque l'on remplace un disque dans son RAID1.

      De plus (je peux retrouver les liens si quelqu'un est intéressé) mais lorsque un des deux disques du RAID1 est subitement mort, il faut faire très attention car on a juste une chance (i.e. un reboot) pour remplacer le disque. Autrement il faut patcher et recompiler le noyau car tout passe en read-only de manière définitive dès le deuxième reboot (sauf à utiliser le patch).

    • [^] # Re: Juste une histoire de ressources de développement

      Posté par (page perso) . Évalué à 3 (+1/-0).

      Les snapshots, même si ça ne sert pas très souvent

      Tu rigoles… Avoir un système de snapshot fonctionnel (ie pas lvm), ça te change la vie. Utilisant massivement zfs, il est rare que la moindre de mes opérations ne commence pas par un snapshot.

  • # Coquille

    Posté par . Évalué à 2 (+1/-0).

    bRTfs ?

    • [^] # Re: Coquille

      Posté par (page perso) . Évalué à 3 (+0/-0).

      Corrigé, merci.

    • [^] # Re: Coquille

      Posté par (page perso) . Évalué à 1 (+0/-0).

      Ainsi que "moronix" --> "Phoronix", sauf si c'est voulu.

      • [^] # Re: Coquille

        Posté par (page perso) . Évalué à 3 (+2/-1).

        merci pour les corrections de coquilles, désolé pour cette bévue. Pour "moronix" la déformation est volontaire. Ce n'est pas de moi, en trainant sur les réseaux sociaux on peut le trouver, je l'interprète comme une certaine frustration, ce site étant certes pratique pour suivre l'actualité, mais parfois spécial dans sa manière de la traiter.

        • [^] # Re: Coquille

          Posté par (page perso) . Évalué à 10 (+20/-6).

          les M$ et compagnie genre moronix, c'est pas un peu gamin?
          Si on n'aime pas ("frustré") la manière de traiter l'info, on n'est pas obligé d'aller voir ce qu'il écrit.

          • [^] # Re: Coquille

            Posté par . Évalué à -9 (+4/-15).

            Putain, j'ai pertinenté Zenitram.

            Merde…

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Coquille

              Posté par . Évalué à 1 (+3/-4). Dernière modification le 03/08/17 à 14:51.

              Tu noteras que personne ne l'as moinssé sur ce coup. Quelqu'un pour se dévouer? :D

              Edit:
              Ah ben quelqu'un l'a fait, zenitram ne perdra pas l'habitude comme ça :p

          • [^] # Re: Coquille

            Posté par . Évalué à 7 (+11/-6).

            les M$ et compagnie genre moronix, c'est pas un peu gamin?

            Et Zenitroll ?

          • [^] # Re: Coquille

            Posté par . Évalué à 3 (+2/-1). Dernière modification le 14/08/17 à 16:46.

            les M$ et compagnie genre moronix, c'est pas un peu gamin?

            si mais c'est rigolol :D

            prout caca zizi

            splash!

          • [^] # Re: Coquille

            Posté par . Évalué à 0 (+1/-2).

            les M$ et compagnie genre moronix, c'est pas un peu gamin?
            Si on n'aime pas ("frustré") la manière de traiter l'info, on n'est pas obligé d'aller voir ce qu'il écrit.

            Si tu n'aimes pas sa manière de commenter, tu n'es pas obligé de le lire.

        • [^] # Re: Coquille

          Posté par . Évalué à 2 (+2/-1).

          Le 'moronix' est mérité, le contenu est très souvent creux ou sensationaliste à outrance… c'est l'équivalent du gala/voici/presse-pq de l'OSS.

  • # Brtfs ?

    Posté par . Évalué à -10 (+4/-20).

    C'est quand même dommage d'écrire un journal sur un objet dont on est même pas capable d'écrire correctement le nom…

    • [^] # Re: Brtfs ?

      Posté par . Évalué à 10 (+14/-0).

      …dont on est même pas capable d'écrire correctement…

      …dont on n'est même pas capable d'écrire correctement…

      C'est quand même dommage de faire une remarque sur l'orthographe d'un sigle en commettant pareille erreur de grammaire.

    • [^] # Re: Brtfs ?

      Posté par . Évalué à 2 (+1/-1).

      Tu dois être parfait toi !

      Sur un clavier azerty, R et T sont proches. Ça peut expliquer la moitié de la typo.

  • # récente acquisition

    Posté par . Évalué à 10 (+10/-0). Dernière modification le 02/08/17 à 15:15.

    https://www.redhat.com/en/about/press-releases/red-hat-acquires-permabit-assets-eases-barriers-cloud-portability-data-deduplication-technology

    With the addition of Permabit’s data deduplication and compression tools to Red Hat Enterprise Linux, Red Hat will be ready to support these organizations as they seek to derive a more efficient storage footprint to power business innovation.

    http://permabit.com/products-overview/albireo-virtual-data-optimizer-vdo/

    VDO (Virtual Data Optimizer) is a ready-to-run software package that delivers block-level deduplication, compression and thin provisioning capabilities to Linux. VDO operates inline at a 4 KB granularity, delivering the best possible balance of performance and data reduction rates. It leverages existing file systems, volume management and data protection to provide the fastest route to market for delivering superior data reduction solutions in Linux storage environments.

    À mon avis ces produits Permabits feront partie d'une option "payante" comme l'était le support de xfs à une époque sur les RHEL 5 et 6 (et peut-être 4 je ne me rappelle plus). Du coup ça aurait été compliqué de justifier à ses propres clients ce genre de produits si la distro de base fournit ce genre de fonctionnalitées out of the box. Et si la solution VDO est plus stable et/ou performante que btrfs ça leur donne un petit coup d'avance sur les concurrents comme suse.

  • # Manque de ressources

    Posté par (page perso) . Évalué à 7 (+4/-0).

    Comme je l'ai lu ailleurs, RedHat n'a pas les ressources en interne pour maintenir Btrfs (les dev sont ailleurs, d'ailleurs certains dev serait partis de chez RedHat pour aller chez Facebook). Du coup, pour maitenir 10 ans de mise à jour sans personne dans la boîte, ce n'est pas étonnant qu'ils préfèrent miser sur autre chose.

    Ce qui est très dommage, c'est qu'ils ne donnent pas d'alternatives dans leur annonce. Du coup, on ne voit pas s'ils veulent envoyer les gens sur zfs ou Permabit + xfs.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Manque de ressources

      Posté par . Évalué à 2 (+1/-1).

      ZFS cela appartient a Oracle qui ne veut pas que cela soit linux compatible (license) donc je pense que RH peut oublier ca.

      En ce qui concerne la deuxieme solution le message au dessus semble y repondre.

      Par contre XFS moi je mettrai pas ca sur mon ordi, pour HPC ok (en gros il y a des generateurs en cas de coupure) mais XFS cela n'aime pas trop les arrets intempestif…

      Vu que ext4 meme si il est tres bien, commene a ne pas etre jeune, que d'apres ce qui est dit dans les commentaires BTRFS et ZFS ne sont pas vraiment fait pour le desktop, on a quoi comme evolution possible?

      • [^] # Re: Manque de ressources

        Posté par (page perso) . Évalué à 5 (+3/-0).

        Vu que ext4 meme si il est tres bien, commene a ne pas etre jeune, que d'apres ce qui est dit dans les commentaires BTRFS et ZFS ne sont pas vraiment fait pour le desktop, on a quoi comme evolution possible?

        Tout envoyer dans le cloud pour se contenter d'un unique disque, sans RAID ou autre joyeuseté, et d'une taille où ext4 reste performant :-D

      • [^] # Re: Manque de ressources

        Posté par . Évalué à 4 (+4/-0). Dernière modification le 02/08/17 à 18:35.

        Ouais, enfin pas fait pour le desktop, un humain normal avec des besoins normaux en termes de perf (pas un serveur, quoi) ne verra pas la différence. La compression est très appréciable sur un laptop avec peu de disque, quand on veut grater de l'espace disque. J'imagine que l'utilisateur lambda va pas être spécialement intéressé par les snapshots et les checksums, mais ça reste pratique.

        Franchement, en deux ans d'utilisation régulière de btrfs sur desktop, même pour du dev et de la compilation, je n'ai pas ressenti de souci de perf notable empiriquement. Avec des benchmarks assassins, je dis pas, mais ma vraie vie voit pas le soucis.

        • [^] # Re: Manque de ressources

          Posté par . Évalué à 3 (+1/-0).

          Oui enfin bon j'ai eu pendant plusieurs annees mon DD avec btrfs et ca fonctionne mais tout de meme j'ai ete touche par les problemes de balancing et heureusement que je ne suis pas un utilisateur normal…

  • # Red Hat != World

    Posté par (page perso) . Évalué à 10 (+9/-0).

    L'explication de Josef Bacik (un des devs de Btrfs) : https://news.ycombinator.com/item?id=14909843

    En gros c'est juste que Red Hat n'a pas l'expertise pour maintenir correctement Btrfs pendant la durée de support d'une release (ils doivent tout backporter parce qu'ils refusent de changer de noyau en cours de route).

    • [^] # Re: Red Hat != World

      Posté par . Évalué à 10 (+7/-0).

      ils refusent de changer de noyau en cours de route

      Ça fait aussi chouiner quelques fans de docker au passage…

      Mais c’est bien ce qu’on, en tout cas moi, attend de RHEL (et donc de CentOS) : le maximum de stabilité/fiabilité, surtout pour le cœur du système. Il s’agit de corriger les bugs du noyau en évitant d’en introduire d’autres avec un nouveau noyau.

      J’ai du mal à croire que l’on puisse avoir une production avec une rolling-release ou même des mises à jour fréquentes du noyau et du système de base (libc,…). C’est trop de surprises potentielles pour un run serein.

      En cas de réel besoin* : backport (donc QA, CI et compagnie…), c’est pas le cas pour Btrfs visiblement. Je pense que RedHat a fait le bon choix, même si ça doit bien décevoir tous ceux qui y ont investi leur temps.

      [*] Financier ou d’image évidemment.

      • [^] # Re: Red Hat != World

        Posté par (page perso) . Évalué à 10 (+10/-2). Dernière modification le 02/08/17 à 22:47.

        Il s’agit de corriger les bugs du noyau en évitant d’en introduire d’autres avec un nouveau noyau.

        Mouais…mais au fil des années de support d'une release cette stratégie devient amha de plus en plus casse-gueule. Rester sur le même noyau et rétroporter les patchs c'est assez facile les 2 ou 3 premières années (si on a une équipe de devs solide comme Red Hat). Mais au fur et à mesure le noyau vanilla diverge inexorablement (12 000 patchs tous les 3 mois quand même !!!) et le rétroportage de patchs devient de la jonglerie en monocycle sur un câble tendu au dessus des chutes du Niagara.
        Je ne dis pas que les serveurs de Prod devraient tous être sous Arch…mais garder un noyau frankenstein pendant plus de 10 ans c'est pas non plus une solution attirante.

        • [^] # Re: Red Hat != World

          Posté par . Évalué à 10 (+9/-0).

          Selon la RHEL Life Cycle (https://access.redhat.com/support/policy/updates/errata), la période où vraiment Red Hat rétroporte des gros changements est de 5 ans (phase "Production 1" selon leur nomenclature).

          Au delà de 5 ans, les phases Production 2 et 3 reçoivent déjà de moins gros changements. Red Hat se limite a corriger des gros bugs, des failles de sécurité et rétroporter des trucs pas trop compliqués.

          Avant la fin de la 1ère phase, généralement la RHEL n+1 est sortie donc si besoin les clients peuvent y migrer.

        • [^] # Re: Red Hat != World

          Posté par (page perso) . Évalué à 6 (+8/-4). Dernière modification le 03/08/17 à 08:22.

          Mais au fur et à mesure le noyau vanilla diverge inexorablement

          C'est pour ça que seuls les patchs critiques sont rétroportés.
          Vraiment, c'est exactement ce qu'on demande à RedHat, et pas pour rien que c'est lui qui est utilisé en professionnel dans les grosses boites (je mets de côté le professionnel qui aime bidouiller et/ou a des trucs court terme) : ne rien casser sans qu'on le décide nous-même (en passant à la version suivante).

          mais garder un noyau frankenstein pendant plus de 10 ans c'est pas non plus une solution attirante.

          Ben si, car on n'a pas du tout envie de fixer un bug qui apparait à cause d'une update de noyau ou autre.
          A noter que "10 ans", c'est pour un logiciel X à nous dans une version Y qu'on ne touche pas et qu'on ne veut pas une nouvelle fonctionnalité (on veut que le logiciel marche toujours tout en étant protégé niveau OS, sans avoir peur lors d'une MAJ de l'OS), ça ne veut pas dire qu'on n'a pas un nouveau noyau pour les nouveaux projets. A noter qu'avec RedHat, c'est plutôt 5 ans, les autres années servent aux fix critiques et pas plus (plus de MAJ des logiciels).

          Bref, ce qui est critiqué est exactement ce pour quoi elle est utilisée : nous laisser libre de choisir quand on casse la compatibilité en upgradant de version, sinon nous assurer la maintenance sur la vielle version. Et ça marche tellement bien qu'en pratique on est passé de cycle de nouvelles versions tous les 2 ans (RHEL jusqu'à la 5) à plutôt 3-4 ans (RHEL 7 a déjà 3 ans et toujours pas de 8 en ligne de mire, faut croire qu'il n'y a pas encore besoin de casser la compatibilité pour des fonctionnalités hypes, ils ont même réussi à y mettre HTTP2 sans casser les ABI)

          Edit : grillé par WhiteCat, ça m'apprendra à ne pas actualiser la page au réveil :), on est bien synchro sur la réaction.

      • [^] # Re: Red Hat != World

        Posté par (page perso) . Évalué à 3 (+2/-1).

        J’ai du mal à croire que l’on puisse avoir une production avec une rolling-release ou même des mises à jour fréquentes du noyau et du système de base (libc,…). C’est trop de surprises potentielles pour un run serein.

        Des mises à jour fréquente peuvent aussi permettre un système plus stable de deux manières :
        (a) chaque mise à jour implique moins de changements donc moins de risque qu'une grosse mise à jour de temps en temps
        (b) si on exerce le processus de mise à jour plus fréquemment, il y a moins de risque de surprises que si on fait juste ça deux fois par an

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Red Hat != World

          Posté par (page perso) . Évalué à 2 (+0/-0).

          J'ai posté ce commentaire un peu vite. Ce que je décris ci-dessus peut permettre un système plus maintenable et potentiellement plus stable tout en permettant de le mettre à jour. Si on veut maximiser la stabilité du système au détriment du reste, évidemment il suffit de ne pas y toucher et de s'assurer que son environnement ne change pas (ce qui n'est typiquement pas possible : la quantité de trafic et de données à traiter change, des failles de sécurité sont découvertes, des nouvelles fonctionnalités sont ajoutées,…).

          Voire aussi https://landing.google.com/sre/book/chapters/release-engineering.html

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Red Hat != World

          Posté par . Évalué à 4 (+1/-0). Dernière modification le 04/08/17 à 20:25.

          il y a moins de risque de surprises que si on fait juste ça deux fois par an

          Pour les gros projets (voire pour les plus petits) on table plutôt sur de N années avec N entre 5 et 10 pour ce qui est de la couche système. Surtout si le projet met déjà un an à être mis en place. Ensuite l’application peut avoir ses propres cycles (si tant est que sa mise à jour reste compatible avec le socle système), c’est une autre histoire.

          Du coup, à part les mises à jour de sécurité ou de bug sérieux il n’y a aucun changement des fonctionnalités de base du système, on n’est pas obligé d’utiliser les rétro-portages. Au bout des N années, si le projet perdure, il s’agit plus d’une migration de celui-ci. Permettant au passage d’améliorer ce qui peut l’être, car dans le laps de temps c’est potentiellement une partie de l’éco-système technique/middleware (sauvegarde, authentification, réseau, db, …) qui aura aussi évolué.

          Cela dit « l’autre » approche, avoir un/des OS/middleware qui évoluent rapidement, en continue, c’est sûrement une condition nécessaire pour pouvoir faire de même au niveau au niveau applicatif, plus précisément pour utiliser des applicatifs nouveaux qui sont développés dès le départ sur des socles récents.

          Je pense qu’un SI doit savoir faire les deux, selon le besoin, même si ce « double pouvoir » a fatalement un coût.

    • [^] # Re: Red Hat != World

      Posté par (page perso) . Évalué à 2 (+0/-0).

      je dois d'abord préciser : bien sûr Red Hat n'est pas le monde entier.
      l'annonce n'est pas un revers en terme de force de développment : il n'y en avait pas.

      c'est juste que Red Hat n'a pas l'expertise pour maintenir correctement Btrfs

      • si c'est un dev de Btrfs, il connait bien les entrailles, mais ne reconnaîtra pas forcément les problèmes de fond.
      • comme poursuivi sur hacker news, est-ce que RH abandonne Btrfs à cause du lack de développeur, ou l'inverse?

      le dév soutient que RH n'a pas la main pour embaucher des dév Btrfs, car les dév font ce qu'ils veulent.
      cet argument me laisse perplexe. Si c'était si vrai l'argument serait applicable à tout.
      comme il le dit lui même, Btrfs n'est simplement pas prêt pour les clients RH.

      Mais j'en conclus que RH saura trouver quelque chose que ses clients utilisent.
      Bon depuis il y a eu l'histoire de "Stratis" mais d'autres histoires suivront!

      c'est plus de ce côté là que je vois l'annonce : pas tant une désuétude de Btrfs
      qu'une promesse de quelque chose d'autre.

      • [^] # Re: Red Hat != World

        Posté par . Évalué à 4 (+2/-0). Dernière modification le 03/08/17 à 13:35.

        Dans le PDF "Stratis Software Design" (https://stratis-storage.github.io/StratisSoftwareDesign.pdf) on peut y lire 2 infos très intéressantes :

        1) Unfortunately, existing VMF (NDLR: "Volume-managing filesystems") aren’t easily used on RHEL. ZFS isn’t an option RHEL can embrace due to licensing (Ubuntu notwithstanding.)

        2) Btrfs has no licensing issues, but after many years of work it still has significant technical issues that may never be resolved

        Bref, les ingénieurs de chez Red Hat ne voit jamais le bout de Btrfs et visiblement ne semblent même plus y croire. Donc ils vont faire autre chose (Stratis) car il y a une demande pour ce genre de système quand même.

  • # Meilleur article sur BTRFS ?

    Posté par . Évalué à 1 (+1/-0).

    Pour ceux qui ne connaîtraient pas BTRFS, ou qui souhaitent en découvrir rapidement et de façon efficace les fonctionnalités majeures, voici le meilleur article que j'ai pu trouver jusqu'à présent:

    https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/

    • [^] # Re: Meilleur article sur BTRFS ?

      Posté par . Évalué à 4 (+3/-0).

      L'article est chouette et bien écrit, cependant je trouve que cela peut porter préjudice à Btrfs en laissant penser que le système de fichier est mature et sans bogues.

      Avec un système de fichier encore en développement comme Btrfs, il faut quand même faire très attention.
      Le genre de commentaire que donne AP plus haut devrait être plus mis en avant pour donner un cadre dans lequel on peut utiliser Btrfs sans s'exposer à trop de problème.

      En particulier quand tout va bien, c'est nickel. Mais dès que vous commencez à avoir des problèmes, réparer les choses avec Btrfs est tout sauf facile. Bien lire le wiki et surtout ne pas hésiter à aller sur la liste de diffusion de dev avant de faire des bêtises irréparable (oui oui aller sur liste de diffusion de dev).

    • [^] # Re: Meilleur article sur BTRFS ?

      Posté par . Évalué à 5 (+3/-0).

      On peut ajouter l'article de Marmotte sur son blog, très bien fait, en Français et bourré de renseignements utiles.

    • [^] # Re: Meilleur article sur BTRFS ?

      Posté par . Évalué à 4 (+4/-1).

      c'est vrai que c'est le meilleur moment de donner envie à quelqu'un de découvrir BTRFS après avoir appris que redhat l'abandonnait…

  • # BTRFS ne serait plus le futur

    Posté par . Évalué à 1 (+0/-0).

    sauf sur Suse

  • # ssd

    Posté par (page perso) . Évalué à 2 (+0/-0).

    Le présent pour la masse, ce n'est pas un systeme optimisé pour les SSD?

    • [^] # Re: ssd

      Posté par . Évalué à 4 (+3/-0).

      La généralisation du SSD implique une plus petite capacité pour la masse (exemple: les laptops d'Apple qui viennent en standard avec 128G/256G).

      Du coup, la data doit être stockée ailleurs, dans le fameux Cloud. C'est ça aussi le besoin de la masse, un Cloud qui fonctionne. Donc il faut un filesystem pour les opérateurs de Cloud. Et ça malheureusement, ça n'existe pas vraiment. Ceux qui font du stockage en masse (type Object Storage) pourront vous le dire, aucun filesystem POSIX n'est taillé pour cet usage (ni btrfs, ni ZFS, ni les autres). Et donc tous les gros opérateurs dev leurs propre solution de stockage sur disque (ou se base des solutions type haystack/bluestore/…).

      • [^] # Re: ssd

        Posté par . Évalué à 2 (+0/-0).

        Aucun filesystem POSIX n'est taillé conçu pour cet usage.

        Le besoin cloud dépasse la capacité du système considéré (une machine + son OS) donc ce ne sont pas des solutions conçues pour une utilisation de ce seul système qui vont répondre.

        Dans les solutions cloud, les fonctions de gestion des metadata, de gestion des permissions, de cache, de réplication, de snapshot, de backup, etc. sont sorties du système local pour intégrer des nœuds spécialisés. Et le FS local peut/doit être beaucoup simplifié.

    • [^] # Re: ssd

      Posté par . Évalué à 2 (+0/-0).

      Le SSD utilise un firmeware pour rendre une interface (S)ATA au système.
      En cela, il n'a pas de particularités par rapport à un HDD et donc ne nécessite pas de FS particulier.
      En vrai, il faut supporté le TRIM et essayer de grouper les écritures le plus possible.
      Mais c'est marginal.

      En revanche, il y a des FS spécialisés pour le flash (UBIFS, F2FS, JFFS2).

  • # Crash

    Posté par . Évalué à 3 (+3/-0).

    J'ai perdu un fs btrfs hier (suite problème hardware cependant) et en effet c'est violent ! le fsck qui rend les choses pires et la partition impossible à monter ça ne m'est pas arrivé depuis longtemps avec de l'ext.

    J'ai toutefois pu récupérer à peu près tout ce que je voulais (deux fichiers texte et les favoris de firefox, merci grep), mais je voulais "explorer" ce FS histoire d'être sur de n'avoir rien d'autre d'important dessus, pas de chance.

    Pour la cause de la panne, j'ai juste branché un gros disque (4to) en USB2 au lieu d'USB3 et lancé une VM dessus, pas assez de courant il a fait n'importe-quoi (les plaisirs de la "norme" USB).

    Note pour plus tard acheter des câbles USB type C vers micro USB pour éviter ce genre d'incidents, j'ai en effet deux disques-dur de ce modèle (Seagate).

    • [^] # Re: Crash

      Posté par . Évalué à 3 (+2/-0).

      Pour en avoir fait l'expérience tout le week-end, tu peux éventuellement récupérer des trucs en

      • étant patient (parce que quand tu mountes il fait des trucs en mode silencieux)
      • en désactivant le max de trucs au mount, genre mount -oro,nospace_cache,norecovery,skip_balance

      J'ai réussi à en récupérer pas mal comme ça… mais bon ça reste un FS qui part allègrement en vrille dès qu'on dépasse les quelques To et qu'il y a des I/O parallèles (je compte plus les hung_tasks avec une stack btrfs dans le dmesg)…

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.