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 AP . Évalué à 10.
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 :
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 Christophe B. (site web personnel) . Évalué à 2.
C'est possible ?
cela mérite d'être étudié merci pour l'info
[^] # Re: Juste une histoire de ressources de développement
Posté par damaki . Évalué à 4.
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 SaintGermain . Évalué à 1.
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 Psychofox (Mastodon) . Évalué à 6.
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 SaintGermain . Évalué à -1.
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 damaki . Évalué à 1.
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 SaintGermain . Évalué à 1.
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 damaki . Évalué à 0. Dernière modification le 03 août 2017 à 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 SaintGermain . Évalué à 1.
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 :
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 Xavier Teyssier (site web personnel) . Évalué à 2.
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 SaintGermain . Évalué à 1.
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 Sufflope (site web personnel) . Évalué à 3.
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 SaintGermain . Évalué à 1.
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 Sufflope (site web personnel) . Évalué à 3.
Pour ma part je fais du RAID, mais le RAID de Linux, avec donc des partitions du type
Linux RAIDpoint 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 SaintGermain . Évalué à 1.
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) :
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 Sufflope (site web personnel) . Évalué à 2. Dernière modification le 04 août 2017 à 14:12.
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).
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 SaintGermain . Évalué à 1.
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 ?
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 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.
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 Sufflope (site web personnel) . Évalué à 3. Dernière modification le 04 août 2017 à 16:10.
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.
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é.
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 SaintGermain . Évalué à 1.
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 Anonyme . Évalué à 3.
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 damaki . Évalué à 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 damaki . Évalué à 0.
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.
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.
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é".
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 damaki . Évalué à 0.
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 Christophe B. (site web personnel) . Évalué à 2.
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 damaki . Évalué à 1.
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 SaintGermain . Évalué à 1.
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 Sébastien Le Ray . Évalué à 3.
À 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 damaki . Évalué à 0.
Ok, merci !
[^] # Re: Juste une histoire de ressources de développement
Posté par SaintGermain . Évalué à 1.
Hormis les VMs, est-ce que tu as d'autres exemples de modifications de fichiers de ce type ?
Dans le cas d'une utilisation pro ou perso ?
Merci !
[^] # Re: Juste une histoire de ressources de développement
Posté par Sébastien Le Ray . Évalué à 2.
C'étaient effectivement des ISOs de VM dans le cas que j'ai en tête
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 ZeroHeure (site web personnel) . Évalué à 5.
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 David Marec (site web personnel) . Évalué à 4.
Enfin, Hammer2, je ne suis pas sûr que Hammer fasse du copy-on-write.
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . Évalué à 1.
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 ZeroHeure (site web personnel) . Évalué à 2.
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 Albert_ . Évalué à 2.
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 ZeroHeure (site web personnel) . Évalué à 4.
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 Albert_ . Évalué à 2.
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 ZeroHeure (site web personnel) . Évalué à 3.
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 SaintGermain . Évalué à 6.
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 Albert_ . Évalué à 1.
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 SaintGermain . Évalué à 3.
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 ZeroHeure (site web personnel) . Évalué à 3.
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 Albert_ . Évalué à 0.
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.
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:
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 Moonz . Évalué à 6.
Tu peux désactiver le CoW dossier par dossier/fichier (typiquement le dossier d’une BDD ou le fichier disque d’une VM).
[^] # Re: Juste une histoire de ressources de développement
Posté par freem . Évalué à 5. Dernière modification le 03 août 2017 à 14:46.
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 Albert_ . Évalué à 0.
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 freem . Évalué à 7.
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 groumly . Évalué à 5.
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 Albert_ . Évalué à 0.
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 freem . Évalué à 3.
Donc tu penses que tout le monde à besoin de VM? Intéressant…
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . Évalué à 1. Dernière modification le 04 août 2017 à 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 Renault (site web personnel) . Évalué à 4.
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.
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).
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 Albert_ . Évalué à 2. Dernière modification le 06 août 2017 à 00:30.
https://www.maketecheasier.com/best-linux-filesystem-for-ssd/
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.
Et?
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 Jean-Baptiste Faure . Évalué à 4.
Plusieurs commentaires de l'article cité contredisent la nécessité de désactiver la journalisation dans le cas d'un SSD.
[^] # Re: Juste une histoire de ressources de développement
Posté par freem . Évalué à 3.
Pourquoi?
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 groumly . Évalué à 9.
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 freem . Évalué à 1.
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 groumly . Évalué à 6.
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 xcomcmdr . Évalué à 2. Dernière modification le 04 août 2017 à 16:48.
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 freem . Évalué à -1.
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 Kerro . Évalué à 4.
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
informatiquesbureautiques de nos clients.[^] # Re: Juste une histoire de ressources de développement
Posté par freem . Évalué à 2.
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 Albert_ . Évalué à 2.
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 Albert_ . Évalué à 2.
Et ext4 sans journal c'est pas forcement le but non?
[^] # Re: Juste une histoire de ressources de développement
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 04 août 2017 à 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 freem . Évalué à 2.
Et donc, il n'y a pas de vérifications sur les autres FS? C'est sûr que c'est parfois chiant, mais c'est lié au fstab et à la politique de la distro si je ne m'abuse, pas au FS.
À moins que ton propos soit que la vérification est plus rapide sur d'autres FS, dans ce cas, ok.
[^] # Re: Juste une histoire de ressources de développement
Posté par kna . Évalué à 3.
Sur ext4 c'est (très) rapide le fsck.
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . Évalué à 0.
Sauf si tu sors le journal non?
Et le journal c'est deconseille avec un SSD…
[^] # Re: Juste une histoire de ressources de développement
Posté par xcomcmdr . Évalué à 4.
J'utilise un le même SSD avec ext4, puis NTFS, pendant des années.
Deux FS qui font plein de journaux.
Il marche aussi bien qu'au premier jour.
Les "conseils" du type "désactivez les journaux", "désactivez l'enregistrement de la date" sont obsolètes depuis des années.
"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 groumly . Évalué à 5.
Clairement, quand on voit ce genre de bench: http://www.anandtech.com/show/8747/samsung-ssd-850-evo-review/4
On se demande bien pourquoi diable on désactiverais le journal, ou quoi que ce soit.
Le,pire cas, c’est 2.5 ans a écrire 100Gb/jour, 20 ans a 20Gb/jour t’as de quoi voir venir quand même.
De ce que je me rappelle d’un talk btrfs, le mec disait en substance “on peut activer les optimizations ssd. Ce qui consiste surtout à désactiver les optimisations des spinners (écrire les blocs les plus proches possible physiquement)”.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Juste une histoire de ressources de développement
Posté par claudex . Évalué à 4.
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 freem . Évalué à 3.
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 claudex . Évalué à 4.
Non, mais c'est un moyen assez "simple" pour le faire.
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 OSUbuntu PhoneWindows Mobile pour le boulot et un Plasma mobile pour le perso.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.
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 SaintGermain . Évalué à 2.
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 JPEC . Évalué à 2.
Je suis en raid1 sur btrfs et du coup ça m'interesse si tu as une procédure éprouvée à suivre en cas de défaillance d'un disque !
[^] # Re: Juste une histoire de ressources de développement
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
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 purplepsycho . Évalué à 2.
bRTfs ?
[^] # Re: Coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Coquille
Posté par Frédéric Massot (site web personnel) . Évalué à 1.
Ainsi que "moronix" --> "Phoronix", sauf si c'est voulu.
[^] # Re: Coquille
Posté par saltimbanque (site web personnel) . Évalué à 3.
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 Zenitram (site web personnel) . Évalué à 10.
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 xcomcmdr . Évalué à -9.
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 freem . Évalué à 1. Dernière modification le 03 août 2017 à 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 rewind (Mastodon) . Évalué à 7.
Et Zenitroll ?
[^] # Re: Coquille
Posté par eingousef . Évalué à 3. Dernière modification le 14 août 2017 à 16:46.
si mais c'est rigolol :D
prout caca zizi
*splash!*
[^] # Re: Coquille
Posté par nizan666 . Évalué à 0.
Si tu n'aimes pas sa manière de commenter, tu n'es pas obligé de le lire.
[^] # Re: Coquille
Posté par gaston . Évalué à 2.
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 Kameramann . Évalué à -10.
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 showtime . Évalué à 10.
…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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# récente acquisition
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 02 août 2017 à 15:15.
https://www.redhat.com/en/about/press-releases/red-hat-acquires-permabit-assets-eases-barriers-cloud-portability-data-deduplication-technology
http://permabit.com/products-overview/albireo-virtual-data-optimizer-vdo/
À 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.
[^] # Re: récente acquisition - Open source
Posté par showtime . Évalué à 1.
Petite précision, apparemment Red Hat a prévu de mettre les logiciels de Permabit en open source.
[^] # Re: récente acquisition - Open source
Posté par claudex . Évalué à 7.
Si c'est comme pour Ansible Tower, on a le temps de voir venir.
« 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
# Manque de ressources
Posté par claudex . Évalué à 7.
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 Albert_ . Évalué à 2.
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 Sufflope (site web personnel) . Évalué à 5.
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 damaki . Évalué à 4. Dernière modification le 02 août 2017 à 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 Albert_ . Évalué à 3.
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 patrick_g (site web personnel) . Évalué à 10.
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 Marotte ⛧ . Évalué à 10.
Ç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 patrick_g (site web personnel) . Évalué à 10. Dernière modification le 02 août 2017 à 22:47.
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 WhiteCat . Évalué à 10.
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 Zenitram (site web personnel) . Évalué à 6. Dernière modification le 03 août 2017 à 08:22.
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).
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 Krunch (site web personnel) . Évalué à 3.
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 Krunch (site web personnel) . Évalué à 2.
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 Marotte ⛧ . Évalué à 4. Dernière modification le 04 août 2017 à 20:25.
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 saltimbanque (site web personnel) . Évalué à 2.
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.
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 WhiteCat . Évalué à 4. Dernière modification le 03 août 2017 à 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 showtime . Évalué à 1.
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 SaintGermain . Évalué à 4.
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 Philip Marlowe . Évalué à 5.
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 Dabowl_75 . Évalué à 4.
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…
[^] # Re: Meilleur article sur BTRFS ?
Posté par Anonyme . Évalué à -4.
OSEF grave de ce fait RedHat non ?
[^] # Re: Meilleur article sur BTRFS ?
Posté par claudex . Évalué à 5.
Non, ils influencent clairement une partie des développements opensources.
« 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: Meilleur article sur BTRFS ?
Posté par Sufflope (site web personnel) . Évalué à 6.
Puisque c'est un contributeur ultra mineur de l'écosystème libre, et notamment du noyau où ils sont quasiment absents, en effet.
Enfin, en tout cas, dans la dimension parallèle où tu vis et où ma phrase précédente est vraie.
# BTRFS ne serait plus le futur
Posté par Dabowl_75 . Évalué à 1.
sauf sur Suse
[^] # Re: BTRFS ne serait plus le futur
Posté par ff9097 . Évalué à 1.
Sur suse c'est le présent
# ssd
Posté par tuxicoman (site web personnel) . Évalué à 2.
Le présent pour la masse, ce n'est pas un systeme optimisé pour les SSD?
[^] # Re: ssd
Posté par ondex2 . Évalué à 4.
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 steph1978 . Évalué à 2.
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 steph1978 . Évalué à 2.
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 Cᴬᴾᵀ Samavor . Évalué à 3.
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 Sébastien Le Ray . Évalué à 3.
Pour en avoir fait l'expérience tout le week-end, tu peux éventuellement récupérer des trucs en
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)…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.