COMPTOIR
  
register

EXT4, BTRFS, F2FS... quel est le meilleur système de fichier sous Linux ?

Lorsque vous branchez un nouveau disque sur votre machine, il faut passer par la case du formatage. Souvent confondu avec un simple effacement, le formatage permet aussi de choisir le format — sans blague... — de votre partition, c’est-à-dire la méthode employée pour garder vos fichiers de manière organisée. Sous Windows, le NTFS reste depuis plus de vingt-cinq ans le format de référence, historiquement accompagné du FAT et de l’exFAT pour les cartes de stockage externe.

 

Néanmoins, ces deux systèmes de fichiers sont loin d’être les seuls. Sous Linux, plusieurs alternatives on vu le jour, comme le BTRFS (un système basé sur le copy-on-write, un paradigme consistant à copier les données et les stocker à un nouvel endroit à chaque modification), le XFS (prévu initialement pour la performance), le F2FS (dont la philosophie consiste à exploiter au mieux un SSD ou une carte SD) ou encore le NILFS2 (également basé sur du copy-on-write, mais mettant l’emphase sur les possibilités de sauvegardes).. Mentionnons également brièvement Apple qui utilisait historiquement le système HFS/HFS+, depuis 2017 remplacé par l’APFS (Apple File System, également à base de copy-on-write). Outre les bricoleurs développant un pilote Windows pour le BTRFS, il est tout à fait possible de retrouver ces formats proche de vous, notamment dans les téléphones portables où l’EXT4 et le F2FS font le bonheur des ROM custom (Android uniquement).

 

linux

 

Bien sûr, il est absurde de juger un système de fichier pour ses seules performances — tentez de créer un sous-volume EXT4 de sauvegarde avant une mise à jour, le BTRFS sera clairement plus indiqué pour ce fait —, mais l’opération est néanmoins riche d’enseignements. Notre confrère Phoronix a ainsi réalisé plusieurs tests en stressant (ou pas) un FireCuda 520 câblé en NVMe selon divers motifs d’accès, et a reporté les résultats pour tous les formats de partitions Linux cités ci-dessus.

 

Globalement, difficile de juger, chaque système ayant ses forces ou ses faiblesses, mais, en moyenne, le XFS s’est imposé en maître — heureusement, vu son objectif ! – suivi de près par le F2FS. Sans surprise, le BTRFS suit en accusant un retard conséquent (copy-on-write oblige), puis vient l’EXT4 du fait de ses bases plus qu’anciennes, et c’est au NILFS2 de fermer la marche, un classement peu étonnant puisque les impératifs de conservation des opérations effectuées doivent bien se ressentir quelque part ! Alors, éclairés pour votre prochaine install' party ?

 

Un poil avant ?

Un i9-10850K en préparation chez Intel ?

Un peu plus tard ...

Qnap introduit QTScloud, le NAS en nuage !

Les 12 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
Message de The manchot pingouin de Bretagne supprimé par un modérateur : hs
par fofo, le Dimanche 05 Juillet 2020 à 07h54  
Ça me semble pas ultra pertinent comme bench :
Donc xterm se lance entre 0.19sec et 1.09sec quand on sollicite le SSD en même temps, ça fait toute la différence

Ça serait bien d'avoir des tests réalistes de trucs qu'on fait réellement (copier des fichiers, compiler un programme, faire un truc lourd genre des filtres dans gimp, ou un rendu 3D).

Comparer la centième de seconde du lancement de xterm pour en faire un classement on touche le fond de l'absurdité
par Un champion du monde en Auvergne-Rhône-Alpes, le Samedi 04 Juillet 2020 à 23h13  
Toujours aussi marrant les flame wars de hippies du libre entre l'un qui
met en avant la longueur de sa barbe pour preuve de sa compétence et
l'autre qui vulgarise l'écriture d'un fichiers 1 kio comme si les I/O
n'avaient pas de buffer R/W.

C'est les X-Men: Days of Past Future!
par fb10e15e96d8, le Samedi 04 Juillet 2020 à 21h45  
par Un hardeur des ragots embusqué, le Samedi 04 Juillet 2020 à 20h11
Je suis programmeur (depuis plus de 40 ans) ...
Ce que tu décris est justement le cas ou tu places le drapeau 'C' sur un répertoire, pour interdire l'utilisation du Copy-On-Write sur les fichiers contenus dans ce répertoire. On l'utilise, justement, sur les répertoires contenant des fichiers style base de données ou images de machines virtuelles, car faire une copie d'un bloc avant de le modifier est couteux en terme d'I/O, et que dans ce cas, il vaut mieux perdre du temps une fois à copier l'intégralité du fichier plutôt que perdre ce même temps pour chaque octet modifié.

Mais dans tous les cas , que tu sois en COW ou en système de fichier classique, quand tu modifies un fichier avec un éditeur autre qu'un moteur de base de données, il faudra bien écrire les données sur le disque à un moment. Et un système COW usera bien moins ton SSD, car il n'écrira QUE les données modifiées, et non l'intégralité du fichier.

Si tu modifies un a un chaque octet d'un fichier d' 1Ko, en enregistrant à chaque fois, avec BTRFS (ou autre COW), tu auras écrit 1024 x 1octet sur ton disque quand avec un système de fichier classique, tu auras écrit 1024 x 1Ko.
par Un hardeur des ragots embusqué, le Samedi 04 Juillet 2020 à 20h11
sinon la fragmentation va exploser
PS : La fragmentation, ça n'existe pas sur un SSD. C'est d'ailleurs pour ça qu'il est fortement déconseillé de défragmenter un SSD. Tu ne gagneras rien en temps d'accès, mais tu génères des écritures pour rien, simplement parce que l'OS ne maitrise pas ou sont les morceaux de fichiers, c'est le boulot du firmware du SSD que s'occuper de ça.
par Un hardeur des ragots embusqué, le Samedi 04 Juillet 2020 à 20h11  
par fb10e15e96d8, le Samedi 04 Juillet 2020 à 19h06
Je pense que tu n'as pas saisi comment fonctionne le copy-on-write.
Je suis programmeur (depuis plus de 40 ans) et j'administre aussi des systèmes Linux depuis plus de 25 ans (mon premier système Linux, v0.99 date de 1993). Je crois savoir ce que je dis... BRTFS utilise les secteurs libres du disque pour y copier tout fichier modifié et comme il tente de minimiser la fragmentation, il recherche le bloc dans lequel le fichier copié complet pourra tenir.
Si vous avez une base de données tenant en un fichier (genre fichier sqlite) il vous faudra au minimum la taille du ficher de cette base en volume libre sur le disque, sinon la fragmentation va exploser et les écritures vont ralentir à la vitesse de l'escargot (car il faudra copier le fichier par petits morceaux).
Résultat: une amplification d'écriture titanesque qui ruine la durée de vie des SSD.

Maintenant, il est vrai que cela fait un bail que je n'ai pas essayé BRTFS, et certains développement récents (comme réutiliser des secteurs marqués pour un TRIM pour le CoW) ont probablement amélioré la situation, du moins tant que votre SSD n'est pas trop rempli...

Reste que je ne choisirais jamais BRTFS pour un SSD...
par Nicolas D., le Samedi 04 Juillet 2020 à 19h09  
par Un hardeur des ragots embusqué, le Samedi 04 Juillet 2020 à 17h50
BRTFS n'est absolument pas adapté aux SSD (bonjour l'amplification d'écriture et nécessité de disposer de gros volumes d'espace libre sur le disque, aussi gros que les fichiers que vous y écrivez, à cause du copy-on-write).

Je suis donc étonné que Phoronix l'ai même retenu pour un test sur une unité NVMe...
L'APFS c'est aussi du copy-on-write, à un moment il faut aussi savoir qu'un SSD c'est fait pour être utilisé. Nous avions fait un test dans la rédac et malgré tous mes SSD en BTRFS j'étais de loin celui qui utilisait le moins son disque par rapport à Windows... Il suffit que la granularité des lectures/écriture soit adaptée pour que le surcoût ne soit pas énorme .
par fb10e15e96d8, le Samedi 04 Juillet 2020 à 19h06  
par Un hardeur des ragots embusqué, le Samedi 04 Juillet 2020 à 17h50
BRTFS n'est absolument pas adapté aux SSD (bonjour l'amplification d'écriture et nécessité de disposer de gros volumes d'espace libre sur le disque, aussi gros que les fichiers que vous y écrivez, à cause du copy-on-write).

Je suis donc étonné que Phoronix l'ai même retenu pour un test sur une unité NVMe...
Je pense que tu n'as pas saisi comment fonctionne le copy-on-write.
Si tu modifies un seul octet dans un fichier de 4Go, tu n'auras (Je simplifie, parce qu'il y a des méta-données, et que la valeur minimale est arrondie à la taille d'un bloc) qu'un seul octet d'écrit sur le disque, et pas 4Go comme tu sembles le penser.

BTRFS Copy-On-Write
par Un ragoteur RGB en Auvergne-Rhône-Alpes, le Samedi 04 Juillet 2020 à 18h12  
Je ne comprendrais jamais cette hype pour les systèmes de fichier chez
les hippies du libre tout comme la course aux chiffons pour la gente
féminine.

Les différences de performances tiennent dans un mouchoir de poche
tandis qu'en réalité seule la taille des clusters est significative
par rapport à l'usage du support de stockage.

Par ailleurs, malgré les promesses théoriques des promotteurs de chaque
système de fichier, nul n'est à l'abri d'une mauvaise implémentation
engendrant instabilités et perte de données.

Pour ma part, toujours satisfait de l'Ext2 by Rémy CARD (cocorico french tech).
par Pascal M., le Samedi 04 Juillet 2020 à 18h10  
par Un hardeur des ragots embusqué, le Samedi 04 Juillet 2020 à 17h50
BRTFS n'est absolument pas adapté aux SSD (bonjour l'amplification d'écriture et nécessité de disposer de gros volumes d'espace libre sur le disque, aussi gros que les fichiers que vous y écrivez, à cause du copy-on-write).

Je suis donc étonné que Phoronix l'ai même retenu pour un test sur une unité NVMe...
c'est un bon moyen de tester l'endurance
par Un ragoteur RGB en Auvergne-Rhône-Alpes, le Samedi 04 Juillet 2020 à 17h58  
par Cristallix, le Samedi 04 Juillet 2020 à 17h49
Vive le ReiserFS 8)
Pas mal le troll sur son auteur...

 

Hans Thomas Reiser (born December 19, 1963) is an American computer
programmer, entrepreneur, and convicted murderer. In April 2008, Reiser
was convicted of the first-degree murder of his wife, Nina Reiser, who
disappeared in September 2006. He subsequently pleaded guilty to a reduced
charge of second-degree murder, as part of a settlement agreement that
included disclosing the location of his wife's body, which he revealed to
be in a shallow grave near the couple's home.


source:
https://en.wikipedia.org/wiki/Hans_Reiser
par Un hardeur des ragots embusqué, le Samedi 04 Juillet 2020 à 17h50  
BRTFS n'est absolument pas adapté aux SSD (bonjour l'amplification d'écriture et nécessité de disposer de gros volumes d'espace libre sur le disque, aussi gros que les fichiers que vous y écrivez, à cause du copy-on-write).

Je suis donc étonné que Phoronix l'ai même retenu pour un test sur une unité NVMe...
par Cristallix, le Samedi 04 Juillet 2020 à 17h49  
Vive le ReiserFS