| View previous topic :: View next topic |
| Author |
Message |
Poussin
l33t
Joined: 08 Jun 2007
Posts: 659
Location: Liège
|
 Posted: Sun Apr 11, 2010 8:47 am Post subject: |
 |
|
Très intéressant tout ça. Je suis assez content que ça ne troll pas dans tous les sens et que pas mal de posts décrivent pas mal les problèmes liés à l'un ou l'autre type de fs.
Je remarque que je dois être le seul a encore disposé de partition JFS (bouhou, ibm c'est le mal...).
Après tout ces commentaires, je me demande si je vais encore garder ma partition de donnée en l'état (pour l'instant: LVM (pour concaténé plusieurs disques en 1 seul partition (j'étais pas trop chaud pour le raid)) + ReiserFS (pour pouvoir augmenter la taille des partoches (et diminuer si un disque RIP))
Juste pour rire, je vais regarder cet aprem si des outils d'analyse du taux de fragmentation existes pour les différents fs que j'utilses sur les différentes machines et faire quelques tests |
|
| Back to top |
|
 |
jcTux
Apprentice
Joined: 29 Dec 2009
Posts: 276
Location: Tours, France
|
| Posted: Sun Apr 11, 2010 8:50 am Post subject: |
|
|
| Leander256 wrote: |
Certes j'ai des performances horribles sur les petits fichiers malgré quelques tentatives de changer les tailles de blocs – il me faut plusieurs minutes pour décompresser les sources du noyau – mais si c'est le prix à payer pour que le FS soit robuste, alors soit. |
J'ai testé XFS.
C'est assez pénible cette lenteur avec les petits fichiers. |
|
| Back to top |
|
|
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Sun Apr 11, 2010 9:54 am Post subject: |
|
|
http://www.ibm.com/developerworks/library/l-fs10.html ça donne quelques tips sur XFS (c'est écrit par le créateur de Gentoo tiens! et pas mal de liens intéressants à la fin) , Leander256 je pense que l'option de montage osyncisdsync est ce qu'il se faut. C'est une histoire de synchro du fs, ça peut s'améliorer via des options de montage il me semble. C'est d'ailleurs aussi pour cela que je conseille XFS sur les laptop: il fait travailler nettement moins le disque, contrairement à reiserfs par exemple et ça a un véritable impact sur l'autonomie.
Pour les petits fichiers c'est pas le point fort de XFS on est d'accord, mais ça s'améliore au formatage ça (pas après). J'ai jamais vu mieux cela dit que reiserfs (3.6, jamais testé le 4 mais j'imagine que c'est pareil) pour cela et c'est d'ailleurs pour ça que je lui dédie les partitions pleines de petits fichiers comme /usr/portage |
|
| Back to top |
|
|
Magic Banana
Veteran
Joined: 13 Dec 2005
Posts: 1912
Location: Belo Horizonte, Minas Gerais, Brasil
|
| Posted: Sun Apr 11, 2010 1:02 pm Post subject: |
|
|
| geekounet wrote: | | Au sujet de BtrFS, c'est une initiative pour créer un nouveau FS linux-only (s'appuyant sur les techno LVM, etc. de Linux), basée sur ext4 (cf. argumentation précédente pour ce point), n'apportant rien de nouveau par rapport à ZFS. |
D'où sors-tu cela ?
Ted T'so (développeur principal de ext3/4) voit Btrfs comme une véritable avancée technologique... contrairement à son ext4 :
| Ryan Paul pour ars technica wrote: | | Despite the fact that Ext4 adds a number of compelling features to the filesystem, T'so doesn't see it as a major step forward. He dismisses it as a rehash of outdated "1970s technology" and describes it as a conservative short-term solution. He believes that the way forward is Oracle's open source Btrfs filesystem, which is designed to deliver significant improvements in scalability, reliability, and ease of management. |
Ted T'so explique aussi que la conception de Btrfs s'inspire, en partie, de Reiser3/4 (et non de ext3/4) :
| Ted T'so wrote: | | People who really like reiser4 might want to take a look at btrfs; it has a number of the same design ideas that reiser3/4 had --- except (a) the filesystem format has support for some advanced features that are designed to leapfrog ZFS, (b) the maintainer is not a crazy man and works well with other LKML developers. |
Et voilà un développeur de ZFS, Valérie Aurora, qui explique que d'un point de vue des fonctionnalités ZFS et Btrfs semblent identiques, mais que la conception de Btrfs est meilleure :
| Valérie Aurora wrote: | In summary, btrfs organizes everything on disk into a btree of extents containing items and data. ZFS organizes everything on disk into a tree of block pointers, with different block sizes depending on the object size. btrfs checksums and reference-counts extents, ZFS checksums and reference-counts variable-sized blocks. Both file systems write out changes to disk using copy-on-write - extents or blocks in use are never overwritten in place, they are always copied somewhere else first.
So, while the feature list of the two file systems looks quite similar, the implementations are completely different. It's a bit like convergent evolution between marsupials and placental mammals - a marsupial mouse and a placental mouse look nearly identical on the outside, but their internal implementations are quite a bit different!
In my opinion, the basic architecture of btrfs is more suitable to storage than that of ZFS. One of the major problems with the ZFS approach - "slabs" of blocks of a particular size - is fragmentation. Each object can contain blocks of only one size, and each slab can only contain blocks of one size. You can easily end up with, for example, a file of 64K blocks that needs to grow one more block, but no 64K blocks are available, even if the file system is full off nearly empty slabs of 512 byte blocks, 4K blocks, 128K blocks, etc. To solve this problem, we (the ZFS developers) invented ways to create big blocks out of little blocks ("gang blocks") and other unpleasant workarounds. In our defense, at the time btrees and extents seemed fundamentally incompatible with copy-on-write, and the virtual memory metaphor served us well in many other respects.
In contrast, the items-in-a-btree approach is extremely space efficient and flexible. Defragmentation is an ongoing process - repacking the items efficiently is part of the normal code path preparing extents to be written to disk. Doing checksums, reference counting, and other assorted metadata busy-work on a per-extent basis reduces overhead and makes new features (such as fast reverse mapping from an extent to everything that references it) possible. |
Elle explique aussi que Btrfs a un avantage majeur sur la concurrence (ZFS inclus) en ce qui concerne la migration de données :
| Valérie Aurora wrote: | Back references give btrfs a major advantage over every other file system in its class because now we can quickly and efficiently migrate data, incrementally check and repair the file system, and check the correctness of reference counts during normal operation. The proof is that btrfs already supports fast, efficient device removal and shrinking of the available storage for a file system. Many other file systems list "shrink file system" as a feature, but it usually ends up implemented inefficiently and slowly and several years late - or not at all. For example, ext3/4 can shrink a file system - by traversing the entire file system searching for data located in the area of the device being removed. It's a slow, fraught, bug-prone process. ZFS still can't shrink a file system.
The result is beautifully generic and elegant: Everything on disk is a btree containing reference counted, checksummed extents of items, organized by <objectid, type> keys. A great deal of the btrfs code doesn't care at all what is stored in the items, it just knows how to add or remove them from the btree. Optimizing disk layout is simple: allocate things with similar keys close together. |
Bref, j'attends avec impatience la stabilisation de Btrfs ! |
|
| Back to top |
|
|
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Sun Apr 11, 2010 2:44 pm Post subject: |
|
|
| Magic Banana wrote: | | Bref, j'attends avec impatience la stabilisation de Btrfs ! |
À voir en pratique. Une stabilisation de FS ça peut prendre du temps, et après viennent les optimisations (c'est pourquoi un FS est toujours en développement des années après sa sortie).
De ce que j'ai lu de l'article c'est juste que BTRFS fragmente moins et perd moins de place dès sa conception. C'est mince comme grosse différence, elle avoue elle même qu'ils ont trouvés le moyen de corriger ça dans ZFS par d'autre moyens (seulement zfs n'a pas d'outil de défragmentation, ça c'est dommage. tu confirmes geekounet ?). Pour le reste c'est pas flagrant. Sinon btrfs s'est fortement inspiré des reiser pas des ext, enfin c'est ce qu'on lit ici et là.
Qui plus est, et il ne faut pas l'oublier: BTRFS arrive quelques années après ZFS (donc il y a forcément un gain d'expérience de l'un vers l'autre, ce qui est tout à fait normal: on s'en va pas recréer la roue tous les 4 matins. D'ailleurs cette histoire de place non perdue sur btrfs c'est hérité des reiser). Et contrairement à ZFS ils ont pas tentés de prendre de risques: on reste sur de bon vieux b-tree tandis que zfs a préféré les hash (plus performants, mais qui a dû complexifier très nettement leur tâche pour garder une empreinte mémoire raisonnable). Sur le papier, zfs est plus novateur que btrfs amha, le coup des snapshots clones par exemple (que BTRFS amène aussi justement pour proposer les mêmes features que ZFS). Pour autant rien ne dis que l'un soit meilleur que l'autre. (Perso je pense que ça sera kif-kif, c'est d'ailleurs pour ça que Sun avait tout à gagner en collant une licence compatible gplv2. On connait la suite...)
Seul l'utilisation et la comparaisons de ces deux FS dans de vrais multiples contextes de travail et sur la durée nous donnerons les vrais valeurs de tel ou tel FS.
En attendant je reste sur XFS moi.  |
|
| Back to top |
|
|
geekounet
Bodhisattva
Joined: 11 Oct 2004
Posts: 3772
Location: Wellington, Aotearoa
|
| Posted: Sun Apr 11, 2010 6:19 pm Post subject: |
|
|
Oui, pas d'outil de defrag pour ZFS à ma connaissance, mais ça ne préoccupe pas tellement je dois dire...
Après, techniquement c'est kif-kif oui, à la différence que l'un est (et restera) Linux-only, alors que l'autre est portable facilement sur tout OS (conçu pour être universel). Ya qu'à voir à quelle vitesse il est apparu sur FreeBSD et a été vite stabilisé, et à quelle vitesse il est en train d'être porté sous NetBSD. 
Qu'on ne me parle pas du problème de licence CDDL pour implémenter ZFS sous Linux, c'est de la pure mauvaise foi. Il suffit de l'implémenter sous forme de module, avec une glue sous GPL, ça ne dérange pas tellement quand c'est avec des drivers proprio apparemment. C'est le choix qu'à fait FreeBSD en tout cas, tout comme pour les modules sous GPL d'ailleurs, qui posent le même soucis.
Perso, je n'aime pas les technos non portables, encourager une énième techno Linux-only ça n'aidera pas les OS libres à avancer et à intéropérer. |
|
| Back to top |
|
|
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Sun Apr 11, 2010 7:31 pm Post subject: |
|
|
| geekounet wrote: |
Après, techniquement c'est kif-kif oui, à la différence que l'un est (et restera) Linux-only, alors que l'autre est portable facilement sur tout OS (conçu pour être universel). Ya qu'à voir à quelle vitesse il est apparu sur FreeBSD et a été vite stabilisé, et à quelle vitesse il est en train d'être porté sous NetBSD.
|
Je suis pas allé voir le code mais apparemment ça vient du fait que la conception de ZFS arrive à faire abstraction du disque, il manipule les données comme si il avait affaire à de la ram, tout en fournissant les même perfs qu'un FS classique (voire meilleures). C'est plus ou moins expliqué dans l'article pointé par Magic Banana. En tout cas là encore c'était un paris risqué et c'est novateur comparé à ce qui se faisait avant. BTRFS n'a pas suivis.
Pour la fragmentation j'imagine que c'est comme XFS: tant que la partition dépasse pas les 80-90% d'utilisation et qu'il ne s'agit pas que de gros fichiers on peut être tranquille oui. |
|
| Back to top |
|
|
Chr0nos
Apprentice
Joined: 26 Feb 2010
Posts: 205
|
| Posted: Mon Apr 12, 2010 5:07 pm Post subject: |
|
|
coté fragmentation de XFS:
je utilise sur un hdd de 1to (en une seulle partition de 932go)
sur le disque je stoque mes films et coté fragmentation... c'est une catastrophe: fragmenté a 98.8%
hors j'utilise le disque a 82%, quand j'ai demandé s'il existais un outi de defragmentation pour xfs on m'a répondu textuelement:
| Quote: |
.:16:59:14:. <Chr0nos> je me demandais, qqun saurais commnent defragmenter efficacement un hdd en XFS ? pck la je suis fragmenté a 98% (sisi:$)
.:17:05:21:. <chpo> Chr0nos: oui, je sais, c est tres simple
.:17:05:38:. <chpo> Chr0nos: tu copie tout ailleurs, tu effce ton XFS et tu recopie tout dessus
.:17:05:45:. <chpo> et voila, c est defragmenté
.:17:06:04:. <chpo> c est pas une blague
|
du coup je suis un peu perplexe, l'ext3 je ne peut pas l'utiliser a cause de sa trop forte consomation de cpu a l'écriture ( j'ai un pauvre amd2200+ qui n'en peut plus :p ) |
|
| Back to top |
|
|
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Mon Apr 12, 2010 5:18 pm Post subject: |
|
|
| Chr0nos wrote: |
hors j'utilise le disque a 82%, quand j'ai demandé s'il existais un outi de defragmentation pour xfs on m'a répondu textuelement:
| Quote: |
.:16:59:14:. <Chr0nos> je me demandais, qqun saurais commnent defragmenter efficacement un hdd en XFS ? pck la je suis fragmenté a 98% (sisi:$)
.:17:05:21:. <chpo> Chr0nos: oui, je sais, c est tres simple
.:17:05:38:. <chpo> Chr0nos: tu copie tout ailleurs, tu effce ton XFS et tu recopie tout dessus
.:17:05:45:. <chpo> et voila, c est defragmenté
.:17:06:04:. <chpo> c est pas une blague
|
|
Belle connerie qu'on t'a pondue là  ce genre de conseil il aurait pu se le garder.
Vas à la page 1 de ce topic, j'ai justement posté un message à propos de l'outil xfs_db ainsi que l'outil de défragmentation xfs_fsr. |
|
| Back to top |
|
|
Chr0nos
Apprentice
Joined: 26 Feb 2010
Posts: 205
|
| Posted: Mon Apr 12, 2010 5:47 pm Post subject: |
|
|
merci j'ai fait un xfs_fsr -v /dev/sdb1
je verais bien ce que cela donne, j'ai été surpris de voir que le fs avais besoin d'etre monté, la ou j'aurais pensé qu'il falais faire en sorte qu'aucune appli ne touche au fs , c'est miracle :p |
|
| Back to top |
|
|
Poussin
l33t
Joined: 08 Jun 2007
Posts: 659
Location: Liège
|
| Posted: Tue Apr 13, 2010 4:53 pm Post subject: |
|
|
Je n'ai pas encore testé, mais trouvé chez les gentanglophones, un petit script d'analyse du taux de fragmentation:
https://forums.gentoo.org/viewtopic-p-3081971.html
Bon, ça prend en argument un répertoire (et non un système de fichiers)... mais ça doit donner une idée. Mais ça a l'avantage de ne pas dépendre du fs justement, et donc de fonctionner avec tous (utilisation de filefrag)
Chez moi, fsck ne me sort pas gentillment le % of non-continuous 
edit:
Je viens de tester sur un sous-répertoire de données (dans un fs en reiserFS de 954G, utilisation à 98%):
98.6899563318777% non contiguous files, 161.275109170306 average fragments.
edit 2:
Je me demande tout de même si ca marche correctement... il me dit que ma partition de boot est fragmentée à 87%.... (ext2 de 32M, 30% d'utilisation) |
|
| Back to top |
|
|
babykart
Guru
Joined: 08 Oct 2004
Posts: 415
|
| Posted: Tue Apr 13, 2010 6:35 pm Post subject: |
|
|
J'ajoute ma pierre ...
ext3 : le peu d'expérience que j'ai dessus est assez catastrophique globalement...
J'ai abandonné reiserfs et reiser4, le premier comme tout le monde à cause de perte de données, le deuxième car j'en avais marre de bidouiller des ebuilds...
Du coup, en prod ou à la maison : full xfs.
Avec un peu de tunning pour les partitions (dans mon cas des volumes logiques LVM) genre :
pour les volumes hébergeant les bases de données :
| Code: | | mkfs.xfs -l size=64m -b size=2048 /dev/vg0/mysql |
pour les volumes hébergeant des petits fichiers :
| Code: | | mkfs.xfs -l size=64m -b size=1024 /dev/vg0/portage |
Le tout monté avec les options noatime,logbufs=8 : les performances me satisfont, fiabilité et stabilité au rdv ...
xfs a tout ce qu'il faut comme outils...
J'attend avec impatience la stabilisation de btrfs qui semble fort prometteur, mais que je n'ai toujours pas testé...
_________________
>> Gentoo-FR <<
----- |
|
| Back to top |
|
|
Chr0nos
Apprentice
Joined: 26 Feb 2010
Posts: 205
|
| Posted: Tue Apr 13, 2010 7:09 pm Post subject: |
|
|
par contre pour ma part j'ai une chose a reprocher a XFS:
ses délais pour la supression des fichiers :s il es vraiment super long pour ca, après je ne supprime pas souvent de fichier donc ca passe ^^ |
|
| Back to top |
|
|
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Tue Apr 13, 2010 7:33 pm Post subject: |
|
|
| Chr0nos wrote: | par contre pour ma part j'ai une chose a reprocher a XFS:
ses délais pour la supression des fichiers :s il es vraiment super long pour ca, après je ne supprime pas souvent de fichier donc ca passe ^^ |
C'est son gros défaut oui. Un répertoire avec des milliers de fichiers à supprimer c'est long.
Je subodore que l'utilisation des B+tree dans sa structure y soit pour quelque chose. Faudrait avoir un article qui détaille ça. |
|
| Back to top |
|
|
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3169
Location: Paris
|
| Posted: Wed Apr 14, 2010 4:40 pm Post subject: |
|
|
Ah bah tiens, ça tombe bien, un petit bench tout frais extX, btrfs, xfs.
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
| Back to top |
|
|
Poussin
l33t
Joined: 08 Jun 2007
Posts: 659
Location: Liège
|
| Posted: Tue May 11, 2010 10:02 am Post subject: |
|
|
| boozo wrote: | | kwenspc wrote: | Ce genre de post c'est du style à avoir chezmoiçamarche.com 
allez à mon tour:
J'utilise XFS partout (sauf /usr/portage pour laquelle je mets du reiserfs 3.6 vu que c'est plein de petits fichiers) depuis des années et ça marche au poil. Jamais aucun problème. (reiserfs par contre si, mais en s'en fout pour /usr/portage ) |
Idem. xfs avec quelques options et reiser3.6 - les râres pb avec ce dernier se sont toujours réparés sans difficultés particulières en revanche.
Sur ces questions de stabilité, et quand on reste dans la plage optimale/adapté pour leur usage bien entendu, je pense malgré tout sans pouvoir étayer mes dires, que les "problèmes" qu'(peut)on rencontre(r) dépendent surtout de l'usage(/stress) qu'ont leur fait subir d'un user à l'autre - i.e. si il y a du tweaking à outrance, du lvm ou des redimensionnements sauvages sinon hasardeux fréquents, du chiffrement, des platrés de raids multiples en To, etc sans compter la combinatoire de tout ces facteurs + du hardware... |
Ca fait un bout de temps que tu as posté mais quelle genre d'options passes-tu au XFS? 
Bien sur, je suppose le standard noatime au montage, mais tu as d'autres choses cool? (montage / création?) |
|
| Back to top |
|
|
boozo
Advocate
Joined: 01 Jul 2004
Posts: 3193
|
| Posted: Tue May 11, 2010 7:08 pm Post subject: |
|
|
Boah je suis vraiment pas tweaker fou je me suis surtout contenté de suivre ceux qui s'y sont collés au travers de quelques lectures sur f.g.o (genre celui d'XFS on steroïds notamment plus les retours d'Enlight, geekounet, etc...)
M'enfin comme la majorité des gens avec du xfs en usage standard on peut simplement s'accomoder des options : noatime,nodiratime,logbufs=8
Allez vite fait, une petite recherche/sélection (non "exo-steeve") de posts sur la question : (1°) ; (2°) ; (3°) ; (4°) ; ...
Edit: 'tain j'me su relu et j'me suis tout juste compru ! faut vraiment que j'arrête d'écrire en automatique moi :/
_________________
" Un psychotique, c'est quelqu'un qui croit dur comme fer que 2 et 2 font 5, et qui en est pleinement satisfait.
Un névrosé, c'est quelqu'un qui sait pertinemment que 2 et 2 font 4, et ça le rend malade ! " |
|
| Back to top |
|
|
Poussin
l33t
Joined: 08 Jun 2007
Posts: 659
Location: Liège
|
| Posted: Tue May 11, 2010 7:32 pm Post subject: |
|
|
merci
Voilà mes lectures pour la soirée  |
|
| Back to top |
|
|
Enlight
Advocate
Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)
|
| Posted: Tue May 18, 2010 4:08 pm Post subject: |
|
|
| Chr0nos wrote: | par contre pour ma part j'ai une chose a reprocher a XFS:
ses délais pour la supression des fichiers :s il es vraiment super long pour ca, après je ne supprime pas souvent de fichier donc ca passe ^^ |
Ça devrait changer sous peu, il y'a eu 3 grands axes de développement en matière de performance après une refactorisation du code (generic B+-Tree). La dernière, qui concerne les delayed logging vise à considérablement décroitre la bande passante utilisée par les logs (de 20 à 6 fois selon les premiers tests annoncés par David Chinner) et devrait une fois pour toutes régler le problème de lenteur de la délétion (entre autres).
Le code a son propre git à part du git de développement habituel d'Xfs (qui est déjà pas mal en avance sur le code de vos noyaux) si quelqu'un disposant de temps et de l'envie de tester souhaite benchmarker la chose.
Pour l'instant je suis toujours en reiser4 cryptcompress (très bien sur les petits fichiers, mais moins sur les plus grands qui de surcroit ne sont pas compressibles) sur mon raid0 principal (plus près de toi mon Dieu) mais avec le peu de fois que je boote le pc je risque pas grand chose...
La prochaine fois, j'expliquerais pourquoi la plupart des benchmarkings désavantagent Xfs par rapport à une utilisation classique. |
|
| Back to top |
|
|
Magic Banana
Veteran
Joined: 13 Dec 2005
Posts: 1912
Location: Belo Horizonte, Minas Gerais, Brasil
|
| Posted: Tue Jul 27, 2010 11:24 pm Post subject: |
|
|
Un benchmark qui compare ZFS sur BSD à Btrfs sur GNU/Linux (et puis UFS et ext4 pour références). La conclusion :
| Michael Larabel pour Phoronix wrote: | | The latest EXT4 and Btrfs file-systems are certainly great and are actually faster than ZFS, at least when compared to FreeBSD's latest ZFS implementation. The only time that ZFS on PC-BSD/FreeBSD 8.1 was actually faster than EXT4 or Btrfs was when performing random writes of small file sizes and a low thread count, however, once the number of threads became too high or the size increased, Btrfs immediately popped back to being the faster file-system. It is also noting that as our earlier Btrfs benchmarks have shown, when enabling the transparent zlib compression in Btrfs, its performance jumps up even more. Btrfs also has automatic optimizations for a solid-state drive. |
|
|
| Back to top |
|
|
Enlight
Advocate
Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)
|
| Posted: Wed Jul 28, 2010 1:56 am Post subject: |
|
|
Les test phoronix sont pas mal à la ramasse et il faut s'en méfier comme de la peste, ça a été mis en évidence à plusieurs reprises par Eric Sandeen :
- mauvais parsing des utilitaires (bonnie++) => chiffres erronés
- comparaison des FS avec des modes de sécurité différents (barrier / nobarrier)
edit 1:
| Quote: | by Eric Sandeenon 2008-12-21T19:12:04+00:00.
Michal Schmidt wrote:
> But I don't trust Phoronix. I guess I'll have to see if I can
> reproduce their results (not on the same hw, alas).
Nor do I. lame mp3 encoding for filesystem perf tests? please.
and:
http://www.phoronix.com/data/img/results/ext4_benchmarks/1.png
is completely utterly wrong and busted. There is no test in bonnie++
which does a "4GB random delete" by default - and ext3 cannot delete 210
4G files per second anyway, which would be obvious to anyone who's tried
deleting a single DVD iso on ext3, for example.
What they're actually reporting from bonnie++ is seeks per second on the
sequential input test (and I'd have to dig to see what that even means.)
So they've misunderstood what the delete test does (it deletes empty
files not 4G files by default), and reported a number that is impossible
to anyone who's tried, due to sloppy test output parsing.
I let them know about this - fairly politely even! - but they apparently
don't care to update the site.
But since it's on the internets it must be true, and this kind of crap
will be taken as the gospel truth for the next decade. Sigh.
Anyway, I don't put much stock in phoronix test reports at this point.
-Eric
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list |
edit 2 :
Pour ceux qui ne le savent pas, Eric est un ancien dev XFS, ancien dans le sens où l bossait pour SGI avant de bosser sur ext3 et ext4 chez redhat, il continue de contribuer à XFS sur son temps libre
A pour pour ce qui est des benchmarks qui désavantagent XFS, la raison est très simple :
La plupart des benchmarks manipulent très peu de données, ce qui avantagent les systèmes de fichiers qui "packent" tout au début du disque là où les accès sont plus rapides. A peu près tous les FS agissent ainsi tandis qu'XFS divise la son espace en "Allocation Groups" et répartit les données entre eux. Les fichiers d'un même répertoire ne vont que dans un seul AG ce qui pour une utilisation réelle offre certains avantages que n'ont pas les autres FS.
- A moins que l'AG en question ne soit blindée, on garanti un seek maximal entre les fichiers appartenant à un même répertoire. Même Reiser4 qui mise énormément sur la localité des références n'offre pas cette garantie en l'absence d'utilisation d'un repacker (attention la technique employée par reiser4 est super habile également, me faites pas dire ce que je n'ai pas dit).
- On diminue la contention des racines des B+Tree car il y'en a un par AG et non un pour tout le FS, ce qui permet un parallélisme accru.
Maintenant dans le scenario type d'un benchmark type compile de kernel sur une partition fraiche d'un To, disperser l'arbre des sources au 4 coins de la partoche, forcément ça va se payer à la compile... en contrepartie, on sait que la dernière lib que l'on vient d'installer ne devrait pas atterrir trop loin des autres libs dont elle dépend. On a donc un design qui en principe devient de plus en plus intéressant à mesure que les partitions se remplissent et que le système vieillit.
NB : pour certains scénarios en raid, il existe des stratégies de placement des AG qui annihilent pratiquement les désavantages précités mais je n'ai pas vraiment regardé comment ça marchait. |
|
| Back to top |
|
|
Magic Banana
Veteran
Joined: 13 Dec 2005
Posts: 1912
Location: Belo Horizonte, Minas Gerais, Brasil
|
| Posted: Wed Jul 28, 2010 6:35 pm Post subject: |
|
|
| En même temps, les tests auxquels je fais référence ne concernent pas XFS, n'utilisent pas Bonnie++. et les paramètres choisis sont ceux par défaut... |
|
| Back to top |
|
|
Leander256
l33t
Joined: 05 Jul 2003
Posts: 910
Location: Singapour
|
| Posted: Wed Jul 28, 2010 8:30 pm Post subject: |
|
|
Ah btrfs la bonne blague...
J'ai voulu le tester pour voir ce que ça donnait avec l'arbre de portage sur un noyau 2.6.34 (vanilla). J'ai une partition dédiée de 512Mo, je stocke les distfiles dans une autre partition. Pour l'instant avec reiserfs v3 j'ai 53% de disque utilisé. Quand j'ai lancé le emerge --sync sur la partition btrfs vide, il s'est arrêté à la moitié en se plaignant que le disque était plein! Je ne voyais qu'environ 125Mo de données sur la partition, il y avait donc environ 75% de la partition mangée par les métadonnées ou simplement perdues...
Un problème d'ailleurs décrit sur la ML ici: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg05130.html (merci à Enlight pour me l'avoir indiqué). Si on suit un peu la discussion, il s'avère que les devs de btrfs se sont basés sur le papier d'un chercheur mais ont pris pas mal de libertés pour le coder. Je suis bien placé pour savoir que beaucoup de travaux académiques demandent des adaptations pour pouvoir être utilisés dans la vie réelle, mais leur façon de présenter la chose ainsi que mon test aux résultats catastrophiques me laissent à penser qu'ils ont vraiment fait preuve d'amateurisme sur ce coup-là.
Alors les benchmarks sur les systèmes de fichiers je prends ça avec de grosses pincettes |
|
| Back to top |
|
|
Enlight
Advocate
Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)
|
| Posted: Wed Jul 28, 2010 10:54 pm Post subject: |
|
|
Ouh là oui attends! J'ai embrayé sur xfs parce-que dans mon précédent post j'avais dit que j'expliquerai pourquoi il était souvent désavantagé par les benchmarks.
Après le reste de mes remarques visait juste à dire "je me méfie des benchs phoronix comme de la peste car ils ont une historique de gauffrage assez lourde", et à l'œil je vois pas mal de critiques à faire sur ce benchmark :
- le test gzip compression n'a rien à voir avec la performance des FS et semble à mon sens indiquer un problème général quant aux perfs de l'instal bsd.
- postmark sert a mesurer... pas grand chose en fait...(à moins de savoir très exactement ce que l'on fait!)
- il y'a un truc pas catho sur la 3ème page avec les stats ext4 sur les random writes que j'ai vraiment du mal à gober (edit : cf http://btrfs.boxacle.net/repository/single-disk/2.6.29-rc2/2.6.29-rc2/2.6.29-rc2_Large_file_random_writes_odirect._num_threads=32.html)
Last edited by Enlight on Fri Jul 30, 2010 10:56 pm; edited 1 time in total |
|
| Back to top |
|
|
Enlight
Advocate
Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)
|
| Posted: Thu Jul 29, 2010 12:30 am Post subject: |
|
|
| Link31 wrote: | | geekounet wrote: | | Après pour les fan d'ext3, allez vous renseigner sur la qualité de son code, ce n'est qu'une série de bricolages immondes, il est resté inmaintenable et inextensible pendant des années à cause de ça. Perso je ne choisirai pas un FS dont les potentiels bugs ne sont pas corrigeables rapidement et proprement. |
Entre un FS plein de hacks mais qui fonctionne parfaitement et qui est toujours aussi solide depuis des années, et un FS avec un design de code révolutionnaire et pensé pour être maintenable mais qui n'a pas les qualités du premier, le choix est vite fait. Pour moi, un FS doit être incassable, tout le reste est secondaire (même la qualité du code ou les performances). À moins, évidemment, de valoriser par-dessus tout la qualité du code parce qu'on est prêt à le patcher soi-même en cas de problème... |
Ext3 n'est solide que dans l'imaginaire collectif, dans les mailings lists des devs on peut lire à maintes reprises que les cas où Xfs ressortait des fichiers mis à zéro par mesure de sécurité ext3 restituait des frankenstein.
Ext3 est à mille lieu de garantir l'atomicité des opérations qu'il effectue! Seul un des deux s'est attaqué au problème, et ce n'est pas ext3!
| Quote: | Hans Reiser <reiser@xxxxxxxxxxx> wrote:
>
> Perhaps the following is correct?
>
> By contrast, ext3 in data=journal and data=ordered modes only guarantees
> the atomicity of a single write
> that does not span a page boundary, and it guarantees that its internal
> metadata will not be corrupted even if your application's data is
> corrupted after the crash (due to the application spreading what should be
> committed atomically across more than one block). |
Trop classe le design! ^^
Last edited by Enlight on Thu Jul 29, 2010 1:10 am; edited 1 time in total |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
French
