Salut tout le monde,
Je voulais partager avec vous un article publié le 20/11 par Michael Kromer, sur le site linuxmagazine.
M. Kromer, impliqué dans de nombreux projets opensource, dont l'implémentation de Zarafa (solution opensource pour le courrier), a mis en place un benchmark pour faciliter le choix pour l'administrateur dans l'utilisation d'un système de fichiers plutôt qu'un autre et quelle architecture matérielle il faut privilégier pour ses données.
Pour ce faire, 7 FS ont été testés : ext2, ext3, ext4, Btrfs, XFS, ReiserFS et ZFS (bien que récemment exploitée, via le projet "ZFS sous Linux"). L'os utilisé est OpenSuse dans sa version 12.1, avec un kernel 3.1.10, et un kernel 3.3.6. L'architecture matérielle repose sur du Xeon E5-2643 quadricore avec 32Go de RAM, un contrôleur RAID Sas 9261-8i, deux SSD Intel 710 (totalisant 100Go), et six Toshiba Mk2011TRKB (2To).
Les optimisations cache sont désactivées pour les besoins du test. La première partie du test consistait à mesurer les performances en i/o de disques SSD et HDD, via un kernel 3.1.10, comprenant 2 types de transferts de données : séquentielles et aléatoires. La seconde partie, quant à elle, vient montrer qu'il y a peu d'améliorations dans les performances de lecture/écriture lors d'un passage sur un kernel en version 3.3.6, sauf dans les mesures IOzone pour les systèmes de fichiers ext2 et XFS, sur une architecture SSD.
Ce que le bench nous apprend finalement, c'est la confirmation de l'intérêt du choix de SSD plutôt que de disques traditionnels pour des infrastructures à forts échanges dans les lectures et écritures, ce qui vient confirmer la recommandation. Avec toutefois peu de différences entre les deux technologies sur des transferts séquentiels.
# Faibles perfs pour Btrfs
Posté par Eric P. . Évalué à 9.
Ce que le bench nous apprend aussi, c'est les mauvaises perfs de Btrfs, qu'on nous présente comme le future filesystem par défaut sous Linux.
Ce système de fichiers est le pire dans presque tous les scénarios de test (excepté le sequential write pour lequel ReiserFS fait pire).
On pourrait se dire que Btrfs est en développement actif et que ça s'améliore au fur et à mesure… En fait il semble que ce soit le contraire, Btrfs est le seul filesystem qui est plus lent dans tous les scenarios avec un kernel 3.3.6, comparé au kernel 3.1.10.
Evidemment les données ici sont incomplètes, si ça se trouve les perfs ont été nettement améliorées avec le 3.1, mais ce n'est pas très prometteur…
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
[^] # Re: Faibles perfs pour Btrfs
Posté par Zylabon . Évalué à -1.
Les performances de btrfs importent peu, de toute façon, un disque dur est affreusement lent (un ssd aussi dans une moindre mesure). C'est pas avec la vitesse d'un système de fichier qu'on augmente les performances d'un système (dans le cas général). Donc, oui Btrfs deviendra le système de fichier par défaut, parce qu'il y a des tonnes de fonctionnalités que n'aura jamais ext4 ou XFS.
Please do not feed the trolls
[^] # Re: Faibles perfs pour Btrfs
Posté par Marotte ⛧ . Évalué à 10.
Je comprends ta remarque cependant pour un même support donné c'est bien le FS qui fait différence.
Ça dépend de l'usage, accès aléatoire ou séquentiel mais aussi peu de gros fichiers ou plein de petits.
Ça serait con d'utiliser un FS par défaut plus lent pour 95 % des usages parce que 5 % des utilisateurs vont avoir besoin des fonctionnalités avancées fournis par ce FS.
[^] # Re: Faibles perfs pour Btrfs
Posté par mike.simonson . Évalué à 2.
Pas de bol les 5% en question c'est les admin sys donc si ils trouvent que ça leur simplifie la vie ce sera çà.
Il se contenteront de mettre un disque de plus dans la grappe pour que tu ne sentes pas la différence de performance.
Ça coûte pas cher un ou deux disque à coté d'un admin sys.
[^] # Re: Faibles perfs pour Btrfs
Posté par Marotte ⛧ . Évalué à 3.
J'avais en tête l'informatique personnelle pour laquelle l'admin sys et l'utilisateur sont très souvent confondus.
D'autre part j'aimerais que tu précises les fonctionnalités apportées par btrfs auxquelles tu penses. Snapshot ? Resize à chaud ? Je ne suis pas sûr que ce soit toujours pertinent, même pour un admin sys qui doit gérer des centaines d'utilisateurs.
[^] # Re: Faibles perfs pour Btrfs
Posté par Kioob (site web personnel) . Évalué à 3.
Pour ma part, en tant que simple utilisateur, ce que je vois c'est :
- les snapshots, si intégrés au système de packaging de l'OS, ça doit être intéressant non ? Revenir à un «point de sauvegarde», sans risque ?
- le checksum couplé à du RAID, afin de détecter et corriger automatiquement les blocs défectueux, ça me semble plus qu'appréciable.
- la compression à la volée, pour les softs qui ne le gèrent pas d'eux même (Thunderbird ?)
alf.life
[^] # Re: Faibles perfs pour Btrfs
Posté par Marotte ⛧ . Évalué à 3.
Pour les snapshots OK. Perso j'utilise LVM qui est en quelque sorte une sorte de méta système de fichiers (j'espère pas dire trop de conneries).
Pour le RAID, c'est une couche « au dessous » du FS, géré matériellement c'est mieux.
Pour la compressions à la volée effectivement ça peut être utile, je ne sais pas quels FS le gère. Il n'y a que btrfs ?
[^] # Re: Faibles perfs pour Btrfs
Posté par Kioob (site web personnel) . Évalué à 2.
Je suis aussi utilisateur des snapshots LVM, mais les techniques me semblent très différentes. Un snapshot Btrfs, tu le fais à chaud, ça ne va pas déclencher un «journal replay» quand tu tenteras de monter le snapshot… d'ailleurs, tu n'as pas besoin de le monter, il est directement accessible. Il me semble même qu'il y a une option pour qu'un simple utilisateur puisse gérer ses snapshots.
Le RAID est justement géré différemment par BTRFS : lors de la lecture d'un bloc, grâce au checksum, il peut se rendre compte que le bloc a été altéré/endommagé, et par conséquent il va aller lire sa version «répliquée» sur le second disque. mdadm ne fait pas ça, et je ne connais pas non plus de carte RAID qui le fasse (peut être en RAID 6 en exploitant le bloc de parité ?).
alf.life
[^] # Re: Faibles perfs pour Btrfs
Posté par SauronDeMordor (site web personnel) . Évalué à 2.
je suis tout a fait d accord, admin sys depuis plus de …. années (pfouu ça fait beaucoup), et bien linux arrive a peine a faire ce que faisait Alpha OSF1 en 1995 (advfs) qui a été pas mal repris avec ZFS
en bref, les snapshots, les volumes qu on peut réduire ou augmenter a loisir.
le fait d enlever et d ajouter des devices et même avec une jolie rotation circulaire change tous les disques.
il a en outre l avantage d être aussi un volume manager.
il y a quelque chose de gênant dans l article, on ne sait rien sur le formatage du disque SSD. et si on se plante sur l alignement ou la taille des blocs et bien les perf s écroule drastiquement.
on a aussi des options de montages spécifique aux SSD, tout ça étant dans le flou, on ne peut rien dire.
cela dit pour le grand public, et bien soit il connait et il choisi, soit il connait pas et il accepte le mode par défaut, dans tous les cas cela ne change rien :p
[^] # Re: Faibles perfs pour Btrfs
Posté par Marotte ⛧ . Évalué à 2.
clap clap clap
À part ça mes FS en ext4 je les resize sans problème hein. À chaud pour augmenter la taille. Et oh misère, à froid pour les réduire (ce que je ne fais jamais). Il suffit de les créer à la taille minimum et augmenter au fur et à mesure (merci LVM, augmenter la taille du volume logique, puis du FS).
[^] # Re: Faibles perfs pour Btrfs
Posté par SauronDeMordor (site web personnel) . Évalué à 2.
et tu fais comment si le disque est trop petit pour augmenter?
[^] # Re: Faibles perfs pour Btrfs
Posté par Marotte ⛧ . Évalué à 3.
Si le disque est physiquement trop petit… Tu veux dire en ajoutant un disque ? Btrfs fait ça ? LVM le fait aussi.
[^] # Re: Faibles perfs pour Btrfs
Posté par barmic . Évalué à 5.
Il ne reste donc plus qu'à « bencher », ext4+LVM pour pouvoir comparer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Faibles perfs pour Btrfs
Posté par SauronDeMordor (site web personnel) . Évalué à 3.
j oubliais aussi le: comme je regrette le FSCK sur un système de fichier de 1To :(
[^] # ça tombe bien, je cherche à faire un truc comme ça
Posté par yohann (site web personnel) . Évalué à 1.
Mais je ne suis pas admin sys.
l'idée est justement de créer un machine virtuelle dont on pourra augmenter l'espace disque à chaud
les quelques éléments que j'ai trouvés sur le web parlent plutôt de LVM, mais j'ai pas l'impression que le niveau technique soit très haut et ils datent un peu (exemple:
http://akim.sissaoui.com/linux-attitude/agrandir-ou-reduire-la-taille-dune-partition-sur-linux/
)
en gros voici les questions que je me posent:
1° est-ce possible de créer une machine virtuelle dont on peut augmenter la taille du disque à chaud ?
2° y-a-t'il un intérêt, dans le cas d'un VM de configurer plusieurs disque/partitions ?
3° quel système de fichier utiliser pour une VM ? , avec ou sans LVM ?
[^] # Re: ça tombe bien, je cherche à faire un truc comme ça
Posté par Kioob (site web personnel) . Évalué à 2. Dernière modification le 27 novembre 2012 à 09:46.
1) Oui, je ne connais pas tous les systèmes de virtualisation, mais avec Xen ça fonctionne très bien. A noter que LVM gère depuis peu le «thin provisionning»
2) Oui, ne serait-ce que pour aider à la supervision, en sachant ainsi quelle «application» tire le plus. Mais un simple utilisateur préférera souvent avoir une seule et unique partition pour sa VM
3) Dans la VM, ou à l'extérieur ? Pour de la prod ou du dev ? Les VM sont très différentes ou au contraire ont beaucoup en commun ?
alf.life
[^] # Re: ça tombe bien, je cherche à faire un truc comme ça
Posté par Marotte ⛧ . Évalué à 3.
Les mêmes intérêts que pour une machine physique, par exemple pouvoir faire un snapshot de seulement /var ou /home ou bien pouvoir monter /sbin en lecture seul. Sinon effectivement pour la performance, pour une VM ça doit pas changer grand chose.
Idem. LVM conserve ses avantages sur une VM, l'un étant selon moi de pas avoir besoin de dimensionner ses partitions à priori (au moment de l'installation).
Je ne connais pas Btrfs. Si je comprends bien, il apporte les mêmes fonctionnalités que LVM+ext4 (ou LVM+autre FS)
[^] # Re: Faibles perfs pour Btrfs
Posté par zebra3 . Évalué à 5.
Qui n'en ont pas besoin vu qu'elles sont pour la plupart fournies par d'autres couches non liées à un fs en particulier (des petits trucs comme LVM, le device mapper ou aufs).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Faibles perfs pour Btrfs
Posté par barmic . Évalué à 5.
Oui mais il faudrait faire un benchmark avec ce genre de couches pour pouvoir comparer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Faibles perfs pour Btrfs
Posté par Antoine . Évalué à 3.
En plus, les couches, c'est utile contre les fuites.
[^] # Re: Faibles perfs pour Btrfs
Posté par Kioob (site web personnel) . Évalué à 8.
Pour ma part j'ai vu un gros gain de performances avec Btrfs à l'arrivée du kernel 3.6.x.
Le problème étant la très très forte fragmentation dans le temps, et la défragmentation incompatible avec les snapshots. On se retrouve ainsi avec de magnifiques sauvegardes lues à une vitesse de 800Ko/s.
Bref, pas encore au point, mais néanmoins très prometteur. La compression à la volée fait parfois des merveilles, la vitesse d'écriture en général est très bonne, et le système de snapshot est très appréciable. Laissons lui le temps de se peaufiner.
alf.life
[^] # Re: Faibles perfs pour Btrfs
Posté par Troy McClure (site web personnel) . Évalué à 7.
ça fait quand même plus de 5 ans qu'il se peaufine !
[^] # Re: Faibles perfs pour Btrfs
Posté par Kioob (site web personnel) . Évalué à 8.
Mais buggé comme il est, je t'assure qu'il faut encore lui laisser du temps :D
J'ai jeté un FS hier : j'avais quelques erreurs dans le FS, j'ai donc lancé un «btrfsck --repair», et le FS a morflé (je me suis retrouvé avec 4 PB occupés sur un FS de 500 GB, le block device faisant 1TB… bref, ça m'a saoulé, j'ai formaté).
Et bien que le kernel 3.6 en ait corrigé, il reste encore quelques cas de «deadlock», assez pénible.
J'ai d'ailleurs une autre machine montable uniquement en read-only. En RW le process de montage se freeze indéfiniment (il tourne depuis plus de 24 heures là, sans déclencher la moindre IO… j'attends une quelconque aide de la part des devs…).
alf.life
[^] # Re: Faibles perfs pour Btrfs
Posté par SQP . Évalué à 3.
Et en plus ce problème ne doit pas apparaître sur un simple bench. Ça veut dire qu'en situation réelle l'écart pourrait être pire.
[^] # Re: Faibles perfs pour Btrfs
Posté par claudex . Évalué à 3.
Ce qui est étrange, c'est que les tests de phoronix ont plutot tendance à montrer le contraire.
« 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: Faibles perfs pour Btrfs
Posté par khivapia . Évalué à 8.
c'est les mauvaises perfs de Btrfs
En même temps je me demande quel est le sens de ce genre de benchmark vu qu'il désactive les caches disques et vide le cache RAM et les buffers.
Ça empêche les systèmes de fichiers de faire fonctionner bon nombre de leurs optimisations…
Un peu comme si on faisait des benchmarks de processeurs en désactivant les caches, si tant est que ce soit possible.
[^] # Re: Faibles perfs pour Btrfs
Posté par YBoy360 (site web personnel) . Évalué à 1.
surtout qu'il y a plein d'options pour optimiser Btrfs :
http://www.phoronix.com/scan.php?page=article&item=btrfs_linux37_mounts&num=2
après il y a sans doute des options pour Ext4,
# ZFS
Posté par snotling0 . Évalué à 2.
Où sont les chiffres concernant ZFS ? Ils n'apparaissent pas dans le graphique.
De plus, le test est fait avec du RAID matériel, ce qui va à l'encontre de "l'architecture" ZFS.
Enfin, sans configuration L2ARC / ZIL, là encore ZFS est à son désavantage, ou en tout cas, le test n'exploite pas toutes ses fonctionnalités.
# Pas de cache ?
Posté par moi1392 . Évalué à 9.
Il n'y a pas un soucis aec ces deux phrases ?
et
Si le test est fait pour que l'administrateur puisse faire le on choix, il faut gader le cache, voir utiliser plusieurs options de chaque FS pour voir comment cela réagi.
Alors que si on désactive le cache, on teste plus la partie accès disque (gestion des secteurs, des disques, performances matérielles, etc…)
# wtf
Posté par Guillaume Knispel . Évalué à 9.
Vu la description qui en est faite, ce "bench" à l'air complètement bizarre et je n'arrive pas du tout à comprendre ce qu'il cherche à mesurer : on met une machine absurdement puissante, puis on désactive les "optimisations caches", puis on fait des mesures. Hm ok, mais elles ont quel intérêt ces mesures ??? Ce bench vise à modéliser quoi ?
(Sans même parler du fait que tester ext2 et ReiserFs à l'heure actuelle, c'est aussi un moment WTF en soit si c'est sérieux et pas juste la pour décorer).
[^] # Re: wtf
Posté par madhatter (site web personnel) . Évalué à 2.
ReiserFs tient encore très bien la secousse aujourd'hui. Après, c'est vrai qu'ext2 n'étant pas journalisé, il perd un peu d'intérêt.
There is no spoon...
[^] # Re: wtf
Posté par reno . Évalué à 1.
Il me semble qu'à un moment désactiver les caches en écriture était nécessaire sur les disques IDE pour la fiabilité des systèmes de fichier journalisé car ces disques mentaient en disant qu'ils avaient écrits leur données sur le plateau du disque alors que les données étaient juste dans le cache (mensonge fait pour améliorer leur performance apparente dans les benchmark).
Après il me semblait que c'était un problème (enfin!!) résolu..
[^] # Re: wtf
Posté par farib . Évalué à 2.
C'est pas un mensonge, c'est le principe du cache que de garder la data en mémoire et de les écrire plus tard.
[^] # Re: wtf
Posté par Guillaume Knispel . Évalué à 2.
De plus si de la fiabilité HD est nécessaire, il faut un onduleur.
[^] # Re: wtf
Posté par claudex . Évalué à 4.
Je trouve toujours intéressant de tester des systèmes comme ext2 dans les benchmarks, ça permet de voir s'il y a une régression ou pas.
« 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
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.