Au delà de m’avoir fait découvrir ce nouveau FS, le benchmark est aussi intéressant pour voir à quel point BtrFS est «lent» par rapport à EXT4 / XFS.
Son design en COW est clairement à l’origine de cette différence, mais je ne la pensais pas aussi grande. Bon après si on place la sécurité des données en tête de liste des priorités, y’a pas photo xD
Comme une page en appel une autre, j’ai aussi été supris du nombre de FS qui sorte chaque année !!! Liste sur wikipedia EN, jusqu’à 6 dans l’année !!!(2002 & 2005)
Posté par raphj .
Évalué à 7.
Dernière modification le 14 août 2024 à 11:52.
J'utilise beaucoup Btrfs, notamment pour la fonctionnalité de sous-volumes (et donc de Copy-on-Write) pour faire des sauvegardes incrémentales utilisables comme des sauvegardes complète.
Je m'attendais à ce que Btrfs soit plus lent qu'ext4 et autres FS sans CoW, mais pas autant. Je vois bien que l'objectif était de comparer l'état des FS sans ajustements, mais ce serait intéressant de savoir ce qu'il en est quand on active la compression et qu'on utilise noatime, c'est comme ça que je l'utilise, et j'utilise aussi noatime sur ext4. Je n'ai jamais eu besoin du dernier temps d'accès, et ça a l'air de faire beaucoup d'écritures inutiles, ça fait même peur pour la longévité des SSD (mais ce n'est peut-être plus un problème aujourd'hui ?).
Cela dit, mes serveurs sont sous ext4, seule la partie sauvegarde est en Btrfs. Donc les perfs ne sont pas critiques, par contre ext4 ne répondrait pas à mon besoin. Sur l'ordinateur portable, j'utilise Btrfs (pour la compression, et la possibilité de faire des sous volumes pour expérimenter et jeter), donc là, plus de perf serait sympathique :-)
Pour mes utilisations, ZFS serait une alternative sérieuse, donc une comparaison avec lui serait aussi intéressante. Cela dit, il faudrait vraiment un avantage écrasant que je pour m'embête avec ça, vu que ce n'est pas installé de base. On pourrait penser à la fiabilité, mais en pratique je n'ai pas eu trop de soucis avec Btrfs jusqu'à présent et je ne sais pas ce qu'il en est de la fiabilité de ZFS on Linux non plus.
En tout cas faut que je suive BcacheFS un peu sérieusement, ça a l'air intéressant, y compris comme alternative à Btrfs.
C'est pas dis que tu vois une différence sensible si tu n'a pas un usage intensif des IO. D'autant plus si tes applications profitent d'IO asynchrones (ça ne rend pas forcément plus rapide, mais ça garde les logiciels réactifs).
J'utilise beaucoup Btrfs, notamment pour la fonctionnalité de sous-volumes (et donc de Copy-on-Write) pour faire des sauvegardes incrémentales utilisables comme des sauvegardes complète.
Pour moi une sauvegarde est toujours "complète" sinon ce ne serait pas une sauvegarde.
J'utilise rsync pour sauvegarder des partitions xfs et ext4. Je ne vois pas trop l'intérêt de btrfs, et ce d'autant plus qu'il est moins performant.
Une sauvegarde incrémentale (ou décrémentale) est un détail technique pour créer plus de point de sauvegarde distinct sans en payer des coûts exorbitant (en bande passant et en espace de stockage). C'est juste que ta sauvegarde dépend du dernier full et de l'incrément que tu veux (pour une sauvegarde incrémentale). C'est juste que les FS avec du CoW rendent cet aspect plaquage des 2 très naturel.
Je ne vois pas trop l'intérêt de btrfs, et ce d'autant plus qu'il est moins performant.
Aussi rapide que soit XFS ou EXT4 si tu fait ta sauvegarde à chaud tu n'a pas de garantie de la cohérence de tes fichiers, l'utilisation de snapshot rend cela un peu moins risqué (ou permet de le faire à froid avec des indisponibilité bien plus courtes).
Posté par Maderios .
Évalué à 0.
Dernière modification le 15 août 2024 à 12:36.
Aussi rapide que soit XFS ou EXT4 si tu fais ta sauvegarde à chaud tu n'a pas de garantie de la cohérence de tes fichiers
En 25 ans de sauvegardes avec rsync, je n'ai jamais eu de problèmes de cohérence de fichiers que ce soit avec ext2, reiserfs, ext3 et maintenant avec ext4 et xfs. Règle minimum à respecter, stopper les bases de données.
Ce genre de script qui créée des hard links pour faire des instantanés, ça a l'air d'être une bonne option quand on n'a pas accès a des fonctionnalités natives au FS (et d'ailleurs je vais garder l'idée sous le coude), mais ces dernières me semblent beaucoup plus confortables, fiables et robustes. Et probablement plus légères aussi.
Si tu utilises rsync et que tu ne fais pas de snapshot ou n'utilises pas un nouveau répertoire vide pour la nouvelle copie sur le stockage/ordi de destination, c'est que tu fais de la synchronisation.
Si tu ne fais que de la synchro, ben c'est juste de la synchro, pas du backup. La synchro peut servir pour faire du backup mais sans mécanisme de gestion de rétention de données ce n'est que de la synchro et tu vas écraser des données valides par de la merde si tu as une altération non voulue et non détectée sur le volume d'origine.
tu vas écraser des données valides par de la merde si tu as une altération non voulue et non détectée sur le volume d'origine
Pour moi, faire une sauvegarde/backup, c'est faire une copie des données et du système sur un support externe, au cas où un accident se produirait, c'est tout. Concernant un écrasement de données saines par des données invalides, c'est un risque certain mais je n'ai jamais rencontré cela, peut-être du fait que je ne fais jamais de sauvegarde automatique, méthode dont je me suis toujours méfié.
Posté par mahikeulbody .
Évalué à 3.
Dernière modification le 15 août 2024 à 19:18.
Pour moi, faire une sauvegarde/backup, c'est faire une copie des données et du système sur un support externe, au cas où un accident se produirait, c'est tout.
On a bien compris mais ce n'est pas la définition la plus courante de backup. Disons que c'est du backup a minima. Libre à toi de t'en contenter, bien entendu.
Concernant un écrasement de données saines par des données invalides, c'est un risque certain mais je n'ai jamais rencontré cela.
Suivant la logique "c'est un risque certain mais je ne l'ai jamais rencontré", on pourrait imaginer que tu n'as commencé à faire des backup qu'après avoir été confronté une première fois à une perte de données. Comme beaucoup de gens, tu me diras, sauf que la plupart d'entre eux n'étaient pas conscient du risque, contrairement à toi.
L'expression "données invalides" recouvre plein de cas : corruption silencieuse du support (bitrot, par exemple), suppression d'un fichier dont on pensait ne plus avoir besoin, suppression sans s'en rendre compte d'un paragraphe dans un document ((un ctrl-x au lieu d'un ctrl-c) par exemple), un bug dans un logiciel photo qui rend les metadonnées illisibles dans certains cas, etc… toute chose dont on n'est par forcément conscient quand on lance son backup sa copie (même manuellement).
OK, j'ai fait un petit test de btrfs sur un dd externe, c'est intéressant, principalement pour le backup, le facteur performance n'est donc pas important. Reste la question de l'espace disque apparemment plus occupé qu'avec xfs, il faut que je vérifie si c'est compatible avec mon matériel, voir si la compression arrange les choses.
Une doc succincte https://sebsauvage.net/wiki/doku.php?id=btrfs
Règle minimum à respecter, stopper les bases de données.
C'est peut être le "à chaud" qui n'était pas clair ?
La possibilité de faire des snapshots instantanés (le temps n'est pas corrélé au volume des données), permet d'arrêter tes bases quelques secondes plutôt que quelques dizaines de minutes et donc d'avoir bien moins de choses à resynchroniser quand elles sont de nouveau up et donc moins de fluctuations de charges.
Sur l'ensemble de la procédure la section critique c'est de l'ordre de la minutes (arrêt de la base, création du snapshot, démarrage de la base avec sa synchronisation) au lieu de quelque chose qui est plus de l'ordre de l'heure. Tu peux créer séquentiellement tes snapshots et tout transférer en même temps. Grosso modo ça peut permettre de passer de 1h par machines à 1h tout court
Les bases de données permettent de créer des exports en respectant l'atomicité sans devoir les arrêter. C'est jouable si elles ne sont pas trop grosses.
Arrêter la base de données n'est pas suffisant, rsync ne garantie pas l'atomicité (tu as dit règle minimum, j'ai bien conscience que je ne contredis pas, mais ça semble important de l'expliciter). Je fais comme ça et je n'ai jamais eu de soucis non plus, et au pire une incohérence serait résolu lors de la sauvegarde suivante, mais je sais que ce n'est pas top et que je joue avec le feu.
Un FS comme btrfs sur le serveur permettrait justement de créer un instantané de manière atomique, et après tu lances ton rsync tranquillement sur l'instantané.
Les bases de données permettent de créer des exports en respectant l'atomicité sans devoir les arrêter. C'est jouable si elles ne sont pas trop grosses.
C'est ce que permet la commande mariadb-backup qui crée des sauvegardes incrémentales dans un répertoire choisi mais je prends quand même la précaution de stopper la db, au cas où.
Je lance rsync du serveur vers un sous-volume btrfs, et j'en fait un instantané lecture seule avec la date dans son nom.
Ça fait une sauvegarde incrementale et complète. J'ai l'état complet du stockage pour chaque jour, mais ça ne prend pas la place de la somme des états de chaque jour grâce au fonctionnement des instantanés btrfs. Si seuls quelques mégas on changé sur le serveur depuis la dernière sauvegarde, l'instantané ne prend effectivement que quelques mégas sur le disque de sauvegarde. Mais, à l'utilisation, c'est aussi pratique qu'une sauvegarde complète. Ça permet de faire de très nombreuses sauvegardes pas chères et ultra rapidement.
Seul un FS avec ce genre de fonctionnalités permet ça. C'est un de leurs intérêts. Il y a aussi la compression pour gagner encore de la place, et les vérifications de sommes de contrôle pour l'intégrité des données.
La mauvaise performance de BtrFs ne me surprends pas vraiment. Rappelons que jusque récemment BtrFs était instable, un gros effort à été fait sur la correction de bugs et la mise au point des fonctionnalités manquantes. L'optimisation va venir après. Mais c'est clair que ce test montre qu'il y a encore du travail à faire.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Il y a plus de 6a je crois, alors que BTRFS était béni par une infinité d'articles de journalistes linux et quasiment rien sur ZFS, j'ai mis en place ZFS avec cache te logs sur ssd à la place de BTRFS, c'est là que je me suis aperçu des possibilités de ZFS et surtout de la fiabilité et de la facilité d'utilisation de ZFS hors du commun.
J'ai laissé tombé sans regret BTRFS, donc la vitesse est un critère mais à l'usage ce qui compte c'est les possibilités du système de fichier qui compte (fiabilité, auto-réparation, auto-compression (fini les zips), deduplication, snapshots, rollbacks, backups ….) et d'après ce que je crois comprendre BCACHEFS est loin d'être un système de fichier professionnel
# Sans surprise
Posté par Voltairine . Évalué à 3.
Comme d'habitude les gagnants sont Ext4 et XFS ;)
# comparatif intéressant
Posté par Mimoza . Évalué à 4.
Au delà de m’avoir fait découvrir ce nouveau FS, le benchmark est aussi intéressant pour voir à quel point BtrFS est «lent» par rapport à EXT4 / XFS.
Son design en COW est clairement à l’origine de cette différence, mais je ne la pensais pas aussi grande. Bon après si on place la sécurité des données en tête de liste des priorités, y’a pas photo xD
Comme une page en appel une autre, j’ai aussi été supris du nombre de FS qui sorte chaque année !!! Liste sur wikipedia EN, jusqu’à 6 dans l’année !!!(2002 & 2005)
# options avancées, et ZFS
Posté par raphj . Évalué à 7. Dernière modification le 14 août 2024 à 11:52.
J'utilise beaucoup Btrfs, notamment pour la fonctionnalité de sous-volumes (et donc de Copy-on-Write) pour faire des sauvegardes incrémentales utilisables comme des sauvegardes complète.
Je m'attendais à ce que Btrfs soit plus lent qu'ext4 et autres FS sans CoW, mais pas autant. Je vois bien que l'objectif était de comparer l'état des FS sans ajustements, mais ce serait intéressant de savoir ce qu'il en est quand on active la compression et qu'on utilise noatime, c'est comme ça que je l'utilise, et j'utilise aussi noatime sur ext4. Je n'ai jamais eu besoin du dernier temps d'accès, et ça a l'air de faire beaucoup d'écritures inutiles, ça fait même peur pour la longévité des SSD (mais ce n'est peut-être plus un problème aujourd'hui ?).
Cela dit, mes serveurs sont sous ext4, seule la partie sauvegarde est en Btrfs. Donc les perfs ne sont pas critiques, par contre ext4 ne répondrait pas à mon besoin. Sur l'ordinateur portable, j'utilise Btrfs (pour la compression, et la possibilité de faire des sous volumes pour expérimenter et jeter), donc là, plus de perf serait sympathique :-)
Pour mes utilisations, ZFS serait une alternative sérieuse, donc une comparaison avec lui serait aussi intéressante. Cela dit, il faudrait vraiment un avantage écrasant que je pour m'embête avec ça, vu que ce n'est pas installé de base. On pourrait penser à la fiabilité, mais en pratique je n'ai pas eu trop de soucis avec Btrfs jusqu'à présent et je ne sais pas ce qu'il en est de la fiabilité de ZFS on Linux non plus.
En tout cas faut que je suive BcacheFS un peu sérieusement, ça a l'air intéressant, y compris comme alternative à Btrfs.
[^] # Re: options avancées, et ZFS
Posté par barmic 🦦 . Évalué à 3.
C'est pas dis que tu vois une différence sensible si tu n'a pas un usage intensif des IO. D'autant plus si tes applications profitent d'IO asynchrones (ça ne rend pas forcément plus rapide, mais ça garde les logiciels réactifs).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: options avancées, et ZFS
Posté par Maderios . Évalué à 2.
Pour moi une sauvegarde est toujours "complète" sinon ce ne serait pas une sauvegarde.
J'utilise rsync pour sauvegarder des partitions xfs et ext4. Je ne vois pas trop l'intérêt de btrfs, et ce d'autant plus qu'il est moins performant.
[^] # Re: options avancées, et ZFS
Posté par barmic 🦦 . Évalué à 5.
Une sauvegarde incrémentale (ou décrémentale) est un détail technique pour créer plus de point de sauvegarde distinct sans en payer des coûts exorbitant (en bande passant et en espace de stockage). C'est juste que ta sauvegarde dépend du dernier full et de l'incrément que tu veux (pour une sauvegarde incrémentale). C'est juste que les FS avec du CoW rendent cet aspect plaquage des 2 très naturel.
Aussi rapide que soit XFS ou EXT4 si tu fait ta sauvegarde à chaud tu n'a pas de garantie de la cohérence de tes fichiers, l'utilisation de snapshot rend cela un peu moins risqué (ou permet de le faire à froid avec des indisponibilité bien plus courtes).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: options avancées, et ZFS
Posté par Maderios . Évalué à 0. Dernière modification le 15 août 2024 à 12:36.
En 25 ans de sauvegardes avec rsync, je n'ai jamais eu de problèmes de cohérence de fichiers que ce soit avec ext2, reiserfs, ext3 et maintenant avec ext4 et xfs. Règle minimum à respecter, stopper les bases de données.
[^] # Re: options avancées, et ZFS
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3. Dernière modification le 15 août 2024 à 12:48.
De ce que je comprends, tu ne fais pas de sauvegardes incrémentales ?
Donc tu sauvegardes l'intégralité de tes données en plusieurs exemplaires ?
[^] # Re: options avancées, et ZFS
Posté par Maderios . Évalué à 1.
Rsync que j'utilise fait des sauvegardes incrémentales. Il peut même faire des instantanés/snapshots (je n'ai jamais testé)
Cf la page de man https://man.archlinux.org/man/rsync.1
[^] # Re: options avancées, et ZFS
Posté par raphj . Évalué à 3.
Ce genre de script qui créée des hard links pour faire des instantanés, ça a l'air d'être une bonne option quand on n'a pas accès a des fonctionnalités natives au FS (et d'ailleurs je vais garder l'idée sous le coude), mais ces dernières me semblent beaucoup plus confortables, fiables et robustes. Et probablement plus légères aussi.
[^] # Re: options avancées, et ZFS
Posté par Psychofox (Mastodon) . Évalué à 5.
Si tu utilises rsync et que tu ne fais pas de snapshot ou n'utilises pas un nouveau répertoire vide pour la nouvelle copie sur le stockage/ordi de destination, c'est que tu fais de la synchronisation.
ce n'est pas du backup
c'est incrémental
[^] # Re: options avancées, et ZFS
Posté par Maderios . Évalué à 0.
Ah bon ?
[^] # Re: options avancées, et ZFS
Posté par Psychofox (Mastodon) . Évalué à 4.
Si tu ne fais que de la synchro, ben c'est juste de la synchro, pas du backup. La synchro peut servir pour faire du backup mais sans mécanisme de gestion de rétention de données ce n'est que de la synchro et tu vas écraser des données valides par de la merde si tu as une altération non voulue et non détectée sur le volume d'origine.
[^] # Re: options avancées, et ZFS
Posté par Maderios . Évalué à 0.
Pour moi, faire une sauvegarde/backup, c'est faire une copie des données et du système sur un support externe, au cas où un accident se produirait, c'est tout. Concernant un écrasement de données saines par des données invalides, c'est un risque certain mais je n'ai jamais rencontré cela, peut-être du fait que je ne fais jamais de sauvegarde automatique, méthode dont je me suis toujours méfié.
[^] # Re: options avancées, et ZFS
Posté par mahikeulbody . Évalué à 3. Dernière modification le 15 août 2024 à 19:18.
On a bien compris mais ce n'est pas la définition la plus courante de backup. Disons que c'est du backup a minima. Libre à toi de t'en contenter, bien entendu.
Suivant la logique "c'est un risque certain mais je ne l'ai jamais rencontré", on pourrait imaginer que tu n'as commencé à faire des backup qu'après avoir été confronté une première fois à une perte de données. Comme beaucoup de gens, tu me diras, sauf que la plupart d'entre eux n'étaient pas conscient du risque, contrairement à toi.
L'expression "données invalides" recouvre plein de cas : corruption silencieuse du support (bitrot, par exemple), suppression d'un fichier dont on pensait ne plus avoir besoin, suppression sans s'en rendre compte d'un paragraphe dans un document ((un ctrl-x au lieu d'un ctrl-c) par exemple), un bug dans un logiciel photo qui rend les metadonnées illisibles dans certains cas, etc… toute chose dont on n'est par forcément conscient quand on lance
son backupsa copie (même manuellement).[^] # Re: options avancées, et ZFS
Posté par Maderios . Évalué à 2.
OK, j'ai fait un petit test de btrfs sur un dd externe, c'est intéressant, principalement pour le backup, le facteur performance n'est donc pas important. Reste la question de l'espace disque apparemment plus occupé qu'avec xfs, il faut que je vérifie si c'est compatible avec mon matériel, voir si la compression arrange les choses.
Une doc succincte
https://sebsauvage.net/wiki/doku.php?id=btrfs
[^] # Re: options avancées, et ZFS
Posté par barmic 🦦 . Évalué à 3.
C'est peut être le "à chaud" qui n'était pas clair ?
La possibilité de faire des snapshots instantanés (le temps n'est pas corrélé au volume des données), permet d'arrêter tes bases quelques secondes plutôt que quelques dizaines de minutes et donc d'avoir bien moins de choses à resynchroniser quand elles sont de nouveau up et donc moins de fluctuations de charges.
Sur l'ensemble de la procédure la section critique c'est de l'ordre de la minutes (arrêt de la base, création du snapshot, démarrage de la base avec sa synchronisation) au lieu de quelque chose qui est plus de l'ordre de l'heure. Tu peux créer séquentiellement tes snapshots et tout transférer en même temps. Grosso modo ça peut permettre de passer de 1h par machines à 1h tout court
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: options avancées, et ZFS
Posté par raphj . Évalué à 3.
Les bases de données permettent de créer des exports en respectant l'atomicité sans devoir les arrêter. C'est jouable si elles ne sont pas trop grosses.
Arrêter la base de données n'est pas suffisant, rsync ne garantie pas l'atomicité (tu as dit règle minimum, j'ai bien conscience que je ne contredis pas, mais ça semble important de l'expliciter). Je fais comme ça et je n'ai jamais eu de soucis non plus, et au pire une incohérence serait résolu lors de la sauvegarde suivante, mais je sais que ce n'est pas top et que je joue avec le feu.
Un FS comme btrfs sur le serveur permettrait justement de créer un instantané de manière atomique, et après tu lances ton rsync tranquillement sur l'instantané.
[^] # Re: options avancées, et ZFS
Posté par Maderios . Évalué à 1.
C'est ce que permet la commande mariadb-backup qui crée des sauvegardes incrémentales dans un répertoire choisi mais je prends quand même la précaution de stopper la db, au cas où.
[^] # Re: options avancées, et ZFS
Posté par raphj . Évalué à 3.
Je lance rsync du serveur vers un sous-volume btrfs, et j'en fait un instantané lecture seule avec la date dans son nom.
Ça fait une sauvegarde incrementale et complète. J'ai l'état complet du stockage pour chaque jour, mais ça ne prend pas la place de la somme des états de chaque jour grâce au fonctionnement des instantanés btrfs. Si seuls quelques mégas on changé sur le serveur depuis la dernière sauvegarde, l'instantané ne prend effectivement que quelques mégas sur le disque de sauvegarde. Mais, à l'utilisation, c'est aussi pratique qu'une sauvegarde complète. Ça permet de faire de très nombreuses sauvegardes pas chères et ultra rapidement.
Seul un FS avec ce genre de fonctionnalités permet ça. C'est un de leurs intérêts. Il y a aussi la compression pour gagner encore de la place, et les vérifications de sommes de contrôle pour l'intégrité des données.
# sans doute pas étonnant
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2.
La mauvaise performance de BtrFs ne me surprends pas vraiment. Rappelons que jusque récemment BtrFs était instable, un gros effort à été fait sur la correction de bugs et la mise au point des fonctionnalités manquantes. L'optimisation va venir après. Mais c'est clair que ce test montre qu'il y a encore du travail à faire.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Mouaais
Posté par Japamax . Évalué à 0.
Il y a plus de 6a je crois, alors que BTRFS était béni par une infinité d'articles de journalistes linux et quasiment rien sur ZFS, j'ai mis en place ZFS avec cache te logs sur ssd à la place de BTRFS, c'est là que je me suis aperçu des possibilités de ZFS et surtout de la fiabilité et de la facilité d'utilisation de ZFS hors du commun.
J'ai laissé tombé sans regret BTRFS, donc la vitesse est un critère mais à l'usage ce qui compte c'est les possibilités du système de fichier qui compte (fiabilité, auto-réparation, auto-compression (fini les zips), deduplication, snapshots, rollbacks, backups ….) et d'après ce que je crois comprendre BCACHEFS est loin d'être un système de fichier professionnel
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.