# [FS] Quid?

## Poussin

A force d'avoir essayé plein (ok tout est relatif...) systèmes de fichiers et reçu diverses critiques/constatés divers problèmes, je ne sais plus quoi choisir commt FS:

ext2:

Lui il est cool, rapide, possède un outil de defrag (qu'on arrete de me dire "mais non, sous linux ça ne se fragmente jamais"...) mais... pas de journal, donc aie en cas de problème.

ext3:

pas d'outil de defrag, mais un journal... bien qu'un le check apres crash prend une plombe (comparé à jfs par exemple). Par contre, bien qu'il y ait des outils pour ça, il n'est pas prévu pour etre redimensionné (je me trompe?)

jfs:

il a l'air pas mal, mais j'ai cru comprendre que le support allait être stoppé (hey m... je venais de l'utilisé sur mon nouveau portable...)

xfs:

L'air pas mal aussi.... tant qu'il n'y a pas de problème. Il est déconseillé par pas mal de monde.

reizer:

Redim (aussi bien augmentation que diminution, mais faut avouer que le second cas est plutot rare...), mais déjà eu des soucis et perdu pas mal de données.

ext4:

on va encore attendre un peu hein... 

J'utilise LVM, c'est pour ça que le redim m'intéresse bcp. Ca me permet d'ajouter un disque physique et d'en ajouter l'espace à une partition existante. Le problème avec LVM, c'est qu'en cas de crash d'un disque, on peut perdre plus que le contenu de ce disque. Je sais, je pourrais faire du RAID avec redondance, mais j'avoue ne pas avoir trop envie d'utiliser de perdre de l'espace disque  :Wink: 

Je me suis enfin décidé à refroidir un poil les HDD. Ils tournaient entre 50 et 60°C. Maintenant je plafonne à 36-37° en utilisation.

Alors voilà, je me demandais de quelle façon vous gérez vos disques:

- quand faites vous des checks (fréquence? uniquement en cas de problème?)

- quel FS?

Perso, gagner 1% de performance, ça ne m'intéresse pas plus que ça, je ne suis pas si pressé, je préfère quelque chose de +/- robuste...

Je sais que je risque d'avoir pas mal d'avis contraire mais sait-on jamais. J'en ai un peu assez de passer d'un site à l'autre (et du coup d'un avis à l'autre). Je vais installer une machine et je suis coincé devant l'écran, je ne sais vraiment pas quel choix faire (à part boot en ext2  :Wink:  )

----------

## mysix

A te conseiller, reste sur ext3, il est stable et c'est ce qui es recommandé en cas de crash puisque tu as une journalisation.

Mais sinon il y a le BTRFS, c'est le prochain fs à prendre quand il sera stable et fonctionel !

Et si tu as de petits fichiers, tu peux utiliser reiserfs.

----------

## Poussin

quand je compare le redémarrage du systeme apres crash avec du jfs ou du ext3, le jfs met quelques secondes pour mater le journal, l'ext3 scan tout, ça prend des lunes, alors que c'est sensé être journalisé

----------

## razer

 *Poussin wrote:*   

> l'ext3 scan tout, ça prend des lunes, alors que c'est sensé être journalisé

 

Non, il ne scanne pas tout, il est lent à mettre en conformité les inodes en fonction du journal

C'est le principal intérêt d'ext4 d'ailleurs : nettement plus rapide pour le recovering et pour le check

 *Poussin wrote:*   

> 
> 
> ext2 : possède un outil de defrag (qu'on arrete de me dire "mais non, sous linux ça ne se fragmente jamais"...) mais
> 
> ...
> ...

 

Je ne vois justement pas l'intérêt de déframenter un ext2/3/4, si ce n'est pour gagner ce 1 %

A moins que tes partitions soient constament pleines à 95%

----------

## Poussin

 *razer wrote:*   

>  justement pas l'intérêt de déframenter un ext2/3/4, si ce n'est pour gagner ce 1 %
> 
> A moins que tes partitions soient constament pleines à 95%

 

Ca arrive :p

----------

## Link31

Personnellement, je suis un inconditionnel d'ext3. C'est simple, je n'ai JAMAIS perdu le moindre fichier suite à un crash avec ce FS, même les crashs les plus sévères (hors de malheureux fichiers temporaires créés dans le cache du navigateur au mauvais moment...). Quant aux performances, elles ne sont peut-être pas les meilleures parmi tous les FS disponibles, mais elles sont largement correctes.

L'ext4 a l'air intéressant, mais je ne vois pas vraiment l'intérêt de quitter un système de fichiers qui m'a toujours donné entière satisfaction. À mon dernier changement de disque dur avec restauration totale du système depuis une sauvegarde, il y a quelques mois (donc ext4 était déjà là depuis un moment), j'ai donc choisi ext3 en connaissance de cause.

Et au niveau des vérifications :

- chez moi, ext3 n'a jamais pris plus de 10 secondes par partition pour récupérer d'un crash

- les vérifications totales, je les ai configurées pour se lancer tous les 6 mois

----------

## RaX

J'ai ext4 sur toutes mes machines et pour le moment aucuns problèmes.

----------

## kwenspc

Ce genre de post c'est du style à avoir chezmoiçamarche.com   :Laughing: 

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  :Wink: )

----------

## xaviermiller

chez moi : BTRFS avec kernel 2.6.33-RT depuis quelques semaines et tout roule. J'ai eu des crashes (coupures de courant) et n'ai rien perdu.

----------

## Tom_

Pour moi : 

- ext4 pour quasi toutes les partitions sauf 2,

- ext3 sur une partition qui contient tous mes docs persos, que j'ai pas envie de convertir pour le moment,

- et enfin, BTRFS pour /usr/portage.

Ca marche niquel! Aucun problème rencontré.

----------

## boozo

 *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 )

 

 :Laughing:  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...

----------

## razer

 *XavierMiller wrote:*   

> chez moi : BTRFS avec kernel 2.6.33-RT depuis quelques semaines et tout roule. J'ai eu des crashes (coupures de courant) et n'ai rien perdu.

 

Je suis sûr que les coupures étaient volontaires  :Smile: 

 *boozo wrote:*   

> 
> 
> 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...

 

Je pense que tu peux résumer aux mots en gras  :Wink: 

----------

## kwenspc

Tiendez à propos d'xfs (/me fait de la pub, le topic s'y prette bien), y a une pléthore d'outil pour maintenir le truc, et défragmenter si besoin aussi oui (et c'est assez rare).

J'ai une partoche par exemple, qui est pleine de fichiers multimédias donc c'est assez représentatif vu qu'on en a pour toutes les tailles. Cette partition est occupée à 85% sur 120Go et subit pas mal de mouvements tous les jours. Après 4 ans d'utilisation, sans jamais la défragmenter une seule fois:

```

xfs_db -c frag -r /dev/mapper/data

actual 15622, ideal 15232, fragmentation factor 2.50%

```

Voilà voilà  :Mr. Green: . À ce niveau de fragmentation je connais un OS et son superbe FS qui dirait que non, c'est suffisamment peu pour être défragmenté  :Laughing: 

Si je lance xfs_fsr dessus pourtant je peux m'attendre à atteindre un facteur en dessous de 0.5% sans problème. Tiens je vais le lancer justement... 

En attendant, les seuls défauts de XFS, à ma connaissance, sont: 

 on te peut pas réduire la taille d'une partition, seulement l'agrandir. (avec les disques d'aujourd'hui c'est plus vraiment un problème, le Go est pas cher)

 il est très difficile voir impossible parfois (pas tout le temps!) de faire un "undelete". J'étais tombé sur un outil expérimental de sgi qui marchait pas mal, malheureusement j'arrive plus à mettre la main dessus. (Enlight il doit sûrement savoir ^^)

Notez aussi que XFS a été pensé dès sa conception pour des architectures 64bits et pour de la grosse machine. Et puisqu'on est dans la pub, si vous voulez Ext4 c'est un peu comme XFS mais avec 12 ans de retard et des tas de patchs horrib' à faire frémir (notez que la plupart des nouvelles limites d'ext4 par rapport à ext3... atteignent celles de xfs.). D'ailleurs, petite digression,  feu Sun à raté son coup à coller une licence à lui sur ZFS amha, ils auraient damé le pion à ext4 et à BTRFS enfin bon...

Ah voilà, 8min pour défragmenter la fameuse partition, voyons voir:

```

 # xfs_db -c frag -r /dev/mapper/data-music

actual 15242, ideal 15231, fragmentation factor 0.07%

```

 :Cool: 

----------

## geekounet

 *kwenspc wrote:*   

> Notez aussi que XFS a été pensé dès sa conception pour des architectures 64bits et pour de la grosse machine. Et puisqu'on est dans la pub, si vous voulez Ext4 c'est un peu comme XFS mais avec 12 ans de retard et des tas de patchs horrib' à faire frémir (notez que la plupart des nouvelles limites d'ext4 par rapport à ext3... atteignent celles de xfs.). D'ailleurs, petite digression,  feu Sun à raté son coup à coller une licence à lui sur ZFS amha, ils auraient damé le pion à ext4 et à BTRFS enfin bon...

 

Oui , adressage 64bit en interne depuis le début, sous Linux c'est le FS qui supporte la plus grandes taille de volume : 16 EiB (contre 1EiB avec ext4, 16TiB en pratique à cause de limitations de mke2fs) et les plus grandes tailles de fichiers : 8EiB (contre 16TiB avec ext4). De nos jours où le TiB ne coute plus rien et où les base de données sont de plus en plus grandes, un FS qui se limite à quelques TiB ce n'est pas génial. Bon après ZFS supporte 16EiB pour les 2 (XFS est pas trop loin du coup), mais sous Linux c'est pas encore utilisable.  :Smile: 

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. Pour ext4 ils ont du en réécrire une bonne partie, mais ils auraient mieux fait de partir à zéro, ce n'est toujours pas aussi beau que le code de XFS, et de toute façon il n'apporte rien de nouveau par rapport à ce dernier, comme le dit kwenspc, hormis de pouvoir migrer dessus directement depuis du ext3.

Sinon, chez moi c'est du XFS sur mon EeePC, et sur mon NAS MyBook également (choix par défaut par WD d'ailleurs, je ne l'ai toujours pas réinstallé). Le reste c'est du UFS2 sur ma soekris et ZFS sur mon laptop, mon PIII qui fait NAS et mon serveur dédié. (mais c'est du FreeBSD donc pas le sujet ici  :Wink:  ).

----------

## jcTux

 *XavierMiller wrote:*   

> chez moi : BTRFS avec kernel 2.6.33-RT depuis quelques semaines et tout roule. J'ai eu des crashes (coupures de courant) et n'ai rien perdu.

 

J'ai essayé BTRFS avec le noyau 2.6.33-zen1. Tout allait bien jusqu'à un crash. Après redémarrage, plusieurs programmes refusaient de se lancer pour cause de librairies disparues.

Dépité, je me suis remis en ext4.

----------

## Link31

 *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...

----------

## geekounet

 *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...

 

Désolé mais pour être solide ça implique d'avoir un code de qualité exemplaire. Et XFS est largement plus robuste, fiable, stable, épprouvé qu'ext3, ce dernier cassant assez facilement à forte utilisation, j'en ai déjà fait les frais. Et la qualité du code, ce n'est pas forcément pour pouvoir le patcher soi-même, c'est aussi pour que les devs du truc puissent résoudre rapidement et efficacement les problèmes, ce qui n'est pas le cas dans la maintenance d'ext3.

Le fsck.ext3 qui ne fonctionne plus quand ton FS ext3 fait plusieurs TiB avec plusieurs millions de fichiers c'est marrant aussi... parait que ça a été corrigé plusieurs années après avoir découvert le bug, dans le dernier e2fsprogs, en 64bit seulement, mais pas pu tester pour le moment, ce code moisi ne compile pas sur une "vieille" Debian Lenny, tu te rends compte de la question de coder proprement, avec ce genre de cas ? Résultat on prie pour ne pas avoir à rebooter le serveur de backup un jour (au pire on fait sauter le fsck, mais ça reste naze).

----------

## Link31

Tu as de la chance d'avoir les moyens de te payer une machine personnelle munie d'un disque totalisant plusieurs TiB. Mais je ne crois pas que c'est le cas de tout le monde. Sur une machine normale, ext3 est très bien. Sur un supercalculateur un peu plus gros que le tien, avec des partitions de 10 exaoctets par exemple, XFS ne fonctionnera pas. Le tout est de savoir de quel genre d'ordinateur on parle.

----------

## geekounet

Ce n'est pas une machine personnel, c'est au boulot (même si je cumule presque 4TiB chez moi, ce qui n'est pas très cher au passage). Mais il ne me semble pas que la discussion se limite aux machines personnelles de toute façon, et je ne vois pas pourquoi ça serai une raison valable pour autant, ça ne change en rien que ce FS a de grosses lacunes. Et puis si, le XFS fonctionnera très bien avec 10EiB, il en supporte jusqu'à 16.  :Wink:  Et c'est pas un supercalculateur qui aura de telles capacités (ça ne fait que du calcul, pas du stockage), plutôt un gros SAN (qui peut y être lié), mais on en est pas encore à ces dimensions là à notre époque.  :Wink: 

----------

## Pixys

C'est marrant ce sujet qui revient à échéances régulières...

Pour moi c'est Reiser4 en attendant que btrfs soit stable  :Smile:  Il est plus performant que son aïeul reiserFS (ça gratte moins le disque) et surpasse la série ext. Certains ont des pb avec, peut-être que j'ai de la chance, j'utilise LVM, il m'est arrivé de faire le sauvage avec sans perdre de données.

Évidemment, il faut patcher le noyau mais après tout, c'est un détail quand on est sous Gentoo ^_^

Pour ceux qui veulent essayer, les patches se trouvent ici : http://www.kernel.org/pub/linux/kernel/people/edward/reiser4/reiser4-for-2.6/

 *kwenspc wrote:*   

> D'ailleurs, petite digression, feu Sun à raté son coup à coller une licence à lui sur ZFS amha, ils auraient damé le pion à ext4 et à BTRFS enfin bon...

 

Là on touche à la Rolls du FS, je me demande si il existe un FS plus performant tous OS confondus...Last edited by Pixys on Sat Apr 10, 2010 7:31 pm; edited 2 times in total

----------

## geekounet

Vous pouvez aussi lire le topic [débat] systèmes de fichiers : perfs, fiabilité, etc....  :Wink: 

----------

## Fenril

J'ai jamais trop compris les critiques envers ext4, qui est l'évolution logique d'ext3... depuis qu'il est disponible sous Gentoo, je n'ai jamais eu de problème.

Par contre, j'ai voulu faire un fsck sur une de mes partitions ext4, je n'arrive pas à avoir le taux de fragmentation, pourtant sur ma partition racine en ext4 il s'affiche aussi.

----------

## Xytovl

Les débats de 2007 risquent de ne plus être d'actualité avec ext4 et btrfs maintenant.

Les problèmes cités pour ext4 sont des changements du comportement par défaut, ext3 était tellement utilisé partout que certains programmes s'attendaient à avoir cette réaction. En particulier pour les opérations fsync et fclose, ce qui fait qu'avec un manque de chance, qui finira par arrive, on peut se retrouver avec des fichiers vides.

Des patchs ont été intégrés pour les éviter mais fondamentalement c'est plus une erreur des programmes que de ext4 en soi. Le problème c'est qu'en corrigeant d'un côté ou de l'autre on perd des performances, et ext4 n'est plus aussi bon qu'on ne le disait.

Sur mes PC j'ai :

un eeePC en btrfs, qui me sert surtout de preview technologique, en ~x86 parfois des overlays etc, aucune donnée sensible

mon fixe en btrfs pour le / et ext4 pour le /home

les PCs de mes parents en ext4 (et du NTFS sur l'un d'entre eux, beurk)

Ce que j'aime bien de btrfs c'est le raid intégré, plus flexible que le raid logiciel traditionnel, et la compression, qui me sauve la vie sur le eeePC à SSD.

----------

## geekounet

 *Xytovl wrote:*   

> Les débats de 2007 risquent de ne plus être d'actualité avec ext4 et btrfs maintenant.
> 
> Les problèmes cités pour ext4 sont des changements du comportement par défaut, ext3 était tellement utilisé partout que certains programmes s'attendaient à avoir cette réaction. En particulier pour les opérations fsync et fclose, ce qui fait qu'avec un manque de chance, qui finira par arrive, on peut se retrouver avec des fichiers vides.
> 
> Des patchs ont été intégrés pour les éviter mais fondamentalement c'est plus une erreur des programmes que de ext4 en soi. Le problème c'est qu'en corrigeant d'un côté ou de l'autre on perd des performances, et ext4 n'est plus aussi bon qu'on ne le disait.

 

Le débat de 2007 vaut toujours autant, ext4 n'apportant rien de nouveau du tout, vu qu'il reprend les concepts de XFS (y compris le "problème" de fsync que tu cites, que beaucoup ont critiqué avec XFS jusque là, que ces mêmes personnes ne trouvent pas génant avec ext4, va comprendre...), en les intégrant par dessus les fondations pourries d'ext3 (je trouve pas d'autre mot, pour moi c'est comme mettre de nouveaux mâts neufs sur un bateau dont la coque est pourrie et rafistolée de partout).

EDIT: 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 ; alors que cette énergie auraient pu être utilisée pour intégrer (en poussant plus fortement Sun à le licencier sous GPL ou BSD) ou réimplémenter ce dernier, crée bien plus tôt (2005), production-ready, codé proprement, destiné à être un FS universel, etc. Bref ce n'est pas une bonne idée de supporter le projet BtrFS, qui est une enième tentative de favoriser l'exception Linux en coupant toute compabilité avec le reste des OS libres, pour une fois qu'il y avait un espoir dans le monde des FS...

----------

## Leander256

Bon j'avais pas envie de répondre parce que j'avais peur que ça finisse en troll, mais finalement ça va.

Chez moi c'est apparemment comme kwenspc et boozo, XFS à tous les étages (7 partitions) et ReiserFS3 pour /usr/portage. J'utilise du cryptfs + LVM2 sur l'ensemble du système (sauf /boot bien sûr).

Il m'est arrivé plusieurs fois d'oublier de rebrancher mon portable sur le secteur (oui je suis un boulet) et bien sûr je n'ai toujours pas pris la peine de rajouter un script qui met en veille automatiquement en cas de batterie faible (oui je suis un gros boulet), mes partitions XFS n'ont jamais posé un seul problème. Par contre ReiserFS3 trouve toujours des erreurs au redémarrage même si je n'avais pas touché à portage depuis le sync précédent... (je fais un sync deux fois par jour avant le suspend to RAM quand je vais/reviens du boulot).

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. Il y a aussi un léger problèmes quand je manipule de gros fichiers sur le disque système, le noyau met un maximum en tampon mémoire puis d'un seul coup se décide à tout écrire et ça bloque complètement les I/O de ma machine pendant quelques secondes: plus de clavier, plus de souris, écran figé, parfois le wifi se déconnecte. Apparemment c'est un comportement normal de XFS mais je trouve ça quand même étrange que le noyau ne soit plus capable de faire autre chose, si quelqu'un a une idée à ce sujet...

Au passage j'installe aussi mes distros sous qemu/KVM avec du XFS et malgré des plantages récurrents je n'ai pas eu de problème pour l'instant (je les utilise quand même moins que ma Gentoo mais je pense que c'est intéressant de le noter aussi).

----------

## Poussin

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

----------

## jcTux

 *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.

----------

## kwenspc

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

----------

## Magic Banana

 *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.
> ...

 

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 !

----------

## kwenspc

 *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.   :Wink: 

----------

## geekounet

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.  :Smile: 

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.  :Wink: 

----------

## kwenspc

 *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.

----------

## Chr0nos

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
> ...

 

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 )

----------

## kwenspc

 *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:*   
> ...

 

Belle connerie qu'on t'a pondue là  :Neutral:  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.  :Wink: 

----------

## Chr0nos

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

----------

## Poussin

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  :Sad: 

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)

----------

## babykart

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 : 

```
mkfs.xfs -l size=64m -b size=2048 /dev/vg0/mysql
```

pour les volumes hébergeant des petits fichiers : 

```
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é...

----------

## Chr0nos

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 ^^

----------

## kwenspc

 *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.

----------

## El_Goretto

Ah bah tiens, ça tombe bien, un petit bench tout frais extX, btrfs, xfs.

----------

## Poussin

 *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 ) 
> ...

 

Ca fait un bout de temps que tu as posté mais quelle genre d'options passes-tu au XFS?  :Very Happy: 

Bien sur, je suppose le standard noatime au montage, mais tu as d'autres choses cool? (montage / création?)

----------

## boozo

Boah je suis vraiment pas tweaker fou   :Laughing:   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   :Wink:   : (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 :/

----------

## Poussin

merci  :Wink: 

Voilà mes lectures pour la soirée    :Cool: 

----------

## Enlight

 *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.

----------

## Magic Banana

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.

 

----------

## Enlight

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
> ...

 

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  :Smile: 

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.

----------

## Magic Banana

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...

----------

## Leander256

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  :Wink: 

----------

## Enlight

 *Magic Banana wrote:*   

> 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...

 

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

----------

## Enlight

 *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?
> ...

 

Trop classe le design! ^^Last edited by Enlight on Thu Jul 29, 2010 1:10 am; edited 1 time in total

----------

## Enlight

 *kwenspc wrote:*   

>  *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:*   
> ...

 

Oui et non, ça dépend de quelle fragmentation on parle. xfs_fsr ne s'occupe que de la fragmentation des fichiers, alors que le concept peut s'employer pour parler de l'espace libre, du placement des fichiers appartenant à un même répertoire, du remplissage des leafs nodes dans un arbre B...

Après il faut comprendre les chiffres que l'on lit, le fait que la fragmentation soit exprimée en % ça induit pas mal en erreur. 98% de frag. signifie ci "en moyenne un fichier est composé de 2 extents" ce qui pour un mp3, un film etc doit avoir un impact inférieur au 100ème de seconde.

Il ne faut surtout pas croire qu'on est limité à 100%, il n'est pas rare qu'un gros fichier soit composé de 4/500 extents sous ext3, ce qui nous ferait 50 000% de fragmentation.

A choisir, je préfère savoir que mon dernier film de vacances (ce qui est un mauvais exemple car les pc ne devaient pas exister à cette époque...  :Smile:  ) est éclaté en 4, mais qu'en revanche tous les fichiers dans mon /etc sont bien alignés les uns à la suite des autres.

----------

## xaviermiller

Hello,

Je viens d'essayer XFS, et je trouve les performances en compilation de gros paquets catastrophique par rapport à btrfs.

J'ai créé le filesystem avec les options 

```
-isize=1k  -l internal,size=128m -d agcount=2
```

 et monte avec 

```
rw,noatime,nodiratime,attr2,noquota
```

```
# xfs_info /

meta-data=/dev/root              isize=1024   agcount=2, agsize=19176590 blks

         =                       sectsz=512   attr=2

data     =                       bsize=4096   blocks=38353179, imaxpct=25

         =                       sunit=0      swidth=0 blks

naming   =version 2              bsize=4096   ascii-ci=0

log      =internal               bsize=4096   blocks=32768, version=2

         =                       sectsz=512   sunit=0 blks, lazy-count=1

realtime =none                   extsz=4096   blocks=0, rtextents=0

# mount

/dev/root on / type xfs (rw,noatime,nodiratime,attr2,noquota)

```

Qu'est-ce qui foire ? A part retourner à btrfs ou un autre fs plus performant, que puis-je faire ?

J'ai l'impression qu'il synce beaucoup trop souvent.

Par contre, la récupération en cas de crash fonctionne assez bien, j'ai pu le vérifier hier soir après une panne de courant.

----------

## Poussin

J'ai +/- le même soucis, le pire étant lors de la copie des fichiers compilés vers leur destination, le système devient très très lent (et pas sur qu'un tmpfs/autre partoche pour la compilation change grand chose)

----------

## Enlight

L'utilisation de l'option delayed loggin (marquée experimentale dans les kernels récents) devrait en principe permettre de gros gains lors d'une compilation. J'avais prévu de l'utiliser sous peu (l'option de montage est "-o delaylog" de mémoire).

Après faut garder à l'esprit les différences en matière de design. BTRFS est un système de fichiers COW qui grosso modo va écrire où il le peut le plus vite possible là on XFS va écrire de manière à optimiser les lectures ultérieures (write once, read many).

A mon avis, pour de la compile, rien ne devrait pouvoir battre un reiser4 cryptcompress avec fibraton .o (ext1 de mémoire), donc pourquoi ne pas séparer /var/tmp/portage par exemple.

----------

## xaviermiller

Je vais déjà essayer delaylog. Merci pour l'info  :Smile: 

----------

## kwenspc

Y a pas de FS parfait pour tout. Mieux vaut en effet sélectionner selon l'utilisation qu'on fera de la partition. /var/, /usr/portage, /tmp, ... etc...

----------

## xaviermiller

En effet, mais pour l'instant, j'étais assez satisfait de BTRFS. Je sens que je vais y retourner  :Wink: 

----------

## Enlight

 *XavierMiller wrote:*   

> Je vais déjà essayer delaylog. Merci pour l'info 

 

s tu peux faire un bench rapide, ce serait sympa!

----------

## xaviermiller

Pas trouvé. Je n'aime pas tweaker avec des options non standard, et suis retourné à BTRFS.

C'est le jour et la nuit pour la suppression en masse de petits fichiers, et mon système est de nouveau réactif.

----------

