mahikeulbody a écrit 1577 commentaires

Sans vouloir relancer un énième débat sur le moinsage, j'avoue ne pas comprendre pourquoi le post ci-dessus est à -4 (au moment où je fais ce commentaire).

Il n'est pas hors-sujet, répond de façon claire et sourcée à un commentaire et ne fait montre d'aucune agressivité.

Je n'ai pas demandé à avoir snap installé sur mon système, ça c'est fait sans mon consentement.

Je ne suis pas sûr de comprendre cette phrase tellement ça me semble gros : tu voudrais que ceux qui produisent une distribution te demandent ton consentement avant chacune de leur décision* ???

* Sachant qu'en principe ils publient des notes de version/mise à jour pour t'informer.

Oui bien sûr, mais apparemment ce n'est pas juste se mettre d'accord sur un format, c'est aussi se mettre d'accord sur des fonctionnalités (bac à sable, sécurité, partage ou non de librairies, etc…).

En production, l'important est de ne pas perdre les données par une bête panne électrique ;-) Cela ne signifie pas que btrfs ne fonctionne pas dans un certain nombre d'autres cas.

btrfs résiste très bien à toutes sortes de pannes y compris la panne électrique (il y a même une remarque intéressante dans l'article ci-après à propos du raid5 qui pourtant n'est actuellement pas recommandé) :

https://unixsheikh.com/articles/battle-testing-data-integrity-verification-with-zfs-btrfs-and-mdadm-dm-integrity.html#btrfs-power-outage

Il est clair que btrfs n'a pas encore la maturité d'un ext4, xfs ou zfs mais il souffre d'un discrédit qui n'est plus justifié à ce jour (hormis sur des points clairement identifiés tel que le raid5). Selon ce que j'ai pu lire ici et là, beaucoup d'expériences négatives rapportées sont soit obsolètes aujourd'hui, soit relèvent de mauvaises manipulations post-incident (la faute à une documentation incomplète/perfectible ou mal suivie). J'ai clairement lu qu'on pouvait aussi se tirer très facilement une balle dans le pied avec zfs.

Facebook, Synology, etc… l'utilisent en production.

Le choix xfs+lvm+mdadm+… de RH est respectable mais n'est pas forcément révélateur de quoi que ce soit sur btrfs tant il existe de raisons non techniques ayant pu aboutir à ce choix plutôt que btrfs. On peut d'ailleurs se demander ce que deviendrait btrfs si on lui ajoutait les moyens mis sur stratis.

Ça aurait peut-être été moins moinsé à la rubrique Liens.

Je viens de jeter un œil sur le document que tu as linké. De ce que je comprends, ils vont pallier à ce problème en dupliquant les méta-données sur le même volume.

Mais cette solution ne peut s'appliquer aux données elles-mêmes (il est bien sûr hors de question de les dupliquer sur un même volume) => contrairement à btrfs ou zfs, stratis (ou toute autre solution basée sur des couches indépendantes) ne peut pas faire de correction d'erreurs sur les données même avec une configuration de type raid.

(sous réserve que j'aie bien compris, je ne suis pas un spécialiste des FS)

pour avoir acheté un vieux tromblon mal entretenu à 2000€.

Il a dit 6000€.

Il semble qu'il y ait un avantage à intégrer toutes les fonctions dans le FS vs. l'assemblage mdadm, lvm, fs.

Je ne retrouve malheureusement pas l'article (et je n'ai pas le temps de chercher davantage aujourd'hui) mais je crois me rappeler que cela concerne la correction d'erreur : mdadm + lvm + fs pourrait détecter une erreur grâce à un checksum mais ne saurait pas la corriger car la connaissance d'où se trouve la donnée redondée (en cas de raid1 par exemple) n'est pas dans la même couche.

on ne peut donc pas déduire de la seule information de ce choix que les autres technologies seraient intrinsèquement moins bonnes sur le plan technique, ou qu’elles seraient même à déconseiller.

Exemple de l'argument donné plus haut contre btrfs.

Il y a/aura du checksum sur les data et metadata (avec correction auto en cas de raid 1/…) ?

En terme de fiabilité, j'en suis désolé hein, mais j'ai une confiance bien plus grande envers RHEL que l'équipe de Mint.

J'aurais pu aussi citer Suse, Synology ou Facebook.

Et les fonctionnalités complémentaires c'est l'intérêt de btrfs, si c'est pour faire la même chose qu'ext4 autant prendre ext4.

Les fonctionnalités complémentaires auxquelles je faisais allusion sont des trucs comme les quotas, par exemple. Les snapshots fonctionnent et ça permet de faire des choses impossibles avec ext4.

En terme de fiabilité, j'en suis désolé hein, mais j'ai une confiance bien plus grande envers RHEL que l'équipe de Mint.

J'ai cité Mint mais aussi et surtout l'inclusion dans le kernel.

C'est un très mauvais message quand l'un des plus grands acteurs dit clairement « on préfère avoir une implémentation de ses fonctionnalités à coté via un nouveau projet plutôt que de continuer avec btrfs ».

Je ne savais pas que RHEL développait un nouveau FS avec du cow pour remplacer btrfs. J'en étais resté au fait qu'ils privilégiaient dorénavant XFS. Tu as un lien ?

Il y a une différence entre simple et pas si compliqué. De plus, la fonctionnalité qui m'intéresse surtout dans btrfs (ou ZFS) ce sont les snapshots sur / (je les utilise comme des points de retour en cas de problème lors d'une mise à jour, pas comme une solution de backup). Or, configurer une Manjaro avec un / en ZFS, je ne sais pas faire simplement.

Je ne savais pas moi non plus et j'attends impatiemment sa disponibilité dans le kernel.

Au fait, ZFS est-il toujours un glouton en mémoire vive ?

w, x et y problématiques se réduisent maintenant raid5/6. A ne pas confondre avec des fonctionnalités complémentaires qui ne sont pas encore toutes pleinement opérationnelles mais qui n'empêchent pas d'utiliser le FS de façon fiable.

Le fait que Redhat ne supporte plus btrfs ne signifie pas que le FS ne vaut rien, c'est un choix d'affectation de ressources. Tu aurais aussi pu voir que btrfs a intégré le kernel et que Mint le propose par défaut.

J'utilise au quotidien btrfs en raid1, y compris pour / avec Timeshift avant chaque mise à jour de ma Manjaro ce qui est d'un grand confort. Il est clair que si on veut un FS avec des snapshots, ZFS représente certainement un choix plus "robuste" à ce jour mais il n'est malheureusement pas disponible de façon simple dans Linux.

ça pourrait avoir une bonne qualité rapidement […]

Cet argument, si on l'oppose à btrfs, ne tient pas vraiment puisque btrfs a déjà une bonne qualité (qui a certes pris beaucoup plus de temps à être obtenue que si on avait pu suivre un chemin de type Stratis au lieu de partir de zéro).

XFS sur LVM

Les fonctionnalités ne sont donc pas tout à fait comparables puisque, sauf erreur de ma part, XFS ne permet pas les snapshots (il a en contrepartie d'autres qualités mais la comparaison des deux filesystems n'est pas le sujet ici).

(n'est-ce pas btrfs ?…)

btrfs a certes mis longtemps à devenir un système de fichiers mature mais maintenant que c'est le cas, quels seraient les avantages de Stratis que tu présentes comme un concurrent fonctionnel ?

Coté relation avec les usagers, je crois qu'il n'y a pas eu de dégradation due au méchant libéralisme : ça a toujours été mauvais. Pour moi cela provient d'une culture d'entreprise axée sur l'excellence technique mais qui a toujours considéré qu'un usager n'était pas un client, juste quelqu'un à qui on rendait "service".

"C'est grasse" et "études littéraires" côte à côte, ça détonne !

C'est que ça montre que son entreprise a des dirigeants et des RH qui sont restés au moyen-âge et ça va en général de paire avec des pratiques de dev d'un autre temps, des sujets de travail pas épanouissants, une culture d'entreprise pourrave.

Cette corrélation me semble sortie d'un chapeau (ce qui en général n'est pas un bon indicateur de véracité mais peut-être as-tu des sources convaincantes).

Non, c'est juste une politique volontaire de la préfecture, rien à voir avec la numérisation.

Dans le cas évoqué ici, je crois que c'est effectivement le vrai problème. Il n'y a pas que la numérisation (qui est un obstacle pour certains mais pas pour tous), d'autres barrières artificielles sont dressées (papiers pas demandés lors du rdv précédent mais soudainement indispensables, par exemple).

Il doit y avoir un malentendu car ce que tu décris me semble impossible avec keepass : si tu as fermé ton fichier on ne peut pas le rouvrir sans saisir le mot de passe, juste en changeant un flag dans un fichier de configuration.

Quelqu'un ici a connaissance du mécanisme que décrit Ysabeau ?

Commentaire supprimé.

Ça me paraît incroyable mais surtout impossible : comment keepass peut-il déchiffrer le fichier sans la clé ?

Je suis allée voir dans le dossier .config et j'ai remplacé "true" par "false" au niveau de "password" dans le fichier KeePass.config.xml

Je ne connaissais pas, ça revalide le précédent password, c'est ça ?