Avant de formater mon nouveau disque dur, j'ai voulu comparer le fantastique nouveau ext4 avec l'antique reiserfs bien moins utilisé mais dont j'étais satisfait.
La semaine dernière j'avais fait un test de remplissage d'un fichier d'1Go avec reiserfs et avec ext4 sur la même partition.
Le résultat était sans appel en faveur de reiserfs (de l'ordre de 20 ou 30% plus rapide)
Sans parler du temps de formatage, ni d'un index fichier énorme (df) pour ext4 contre 33Mo pour reiserfs... sur un disque de 2To.
Cette fois j'ai testé la copie de photos avec rsync (les fichiers font tous à peu près 5Mo).
Résultat inverse.
# ext4 #
sent 36262755009 bytes received 207851 bytes 52064555.43 bytes/sec
total size is 36257698208 speedup is 1.00
real 11m36.337s
user 7m48.121s
sys 8m34.168s
# reiserfs #
sent 36262755009 bytes received 207851 bytes 44852149.49 bytes/sec
total size is 36257698208 speedup is 1.00
real 13m28.466s
user 8m1.522s
sys 11m7.198s
Il faudrait faire des tests intermédiaires, de lecture, etc... ça a sûrement déjà été fait ailleurs par des testeurs intègres (ou pas). On en trouve par exemple ici :
http://linuxfr.org/news/ext3-et-comparatifs-vs-reiserfs
D'après ce petit test, reiserfs semble donc plus adapté pour les très gros fichiers, comme les videos, images iso et grosses archives, comme le mentionne la page de wikipedia sur reiserfs http://fr.wikipedia.org/wiki/ReiserFS . Ce qui ne devrait pas être étonnant puisqu'il utilise arbre B ( http://fr.wikipedia.org/wiki/Arbre_B ).
Cependant comme les medias de stockage ont tendance à grossir et avec eux la taille des fichiers multimedias, qui représentent quand même l'essentiel des usages pour ces disques... reiserfs reviendra-t-il à la mode un jour ? et reiser4 sera-t-il un jour utilisable sans refaire son noyau ?? ou existe-t-il d'autres raisons qui feront qu'il y a mieux et qu'il y aura mieux ?
En d'autres termes, ai-je raison d'utiliser reiserfs pour mes disques de sauvegarde ?
Btrfs ne me semble pas adapté aujourd'hui car d'après wikipedia il est encore expérimental et développé par une société dont on peut se méfier sur son intérêt pour le libre...
Logs :
# umount /dev/sda1;mkfs.ext4 -L "mnt" /dev/sda1;mount /dev/sda1 /mnt
umount: /dev/sda1: not mounted
mke2fs 1.41.12 (17-May-2010)
Étiquette de système de fichiers=mnt
Type de système d'exploitation : Linux
Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2)
« Stride » = 1 blocs, « Stripe width » = 0 blocs
122101760 i-noeuds, 488378368 blocs
24418918 blocs (5.00%) réservés pour le super utilisateur
Premier bloc de données=0
Nombre maximum de blocs du système de fichiers=4294967296
14905 groupes de blocs
32768 blocs par groupe, 32768 fragments par groupe
8192 i-noeuds par groupe
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
Écriture des tables d'i-noeuds : complété
Création du journal (32768 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété
Le système de fichiers sera automatiquement vérifié tous les 31 montages ou
après 180 jours, selon la première éventualité. Utiliser tune2fs -c ou -i
pour écraser la valeur.
# time rsync -a --stats /dcim/ /mnt/
Number of files: 11096
Number of files transferred: 10897
Total file size: 36257698208 bytes
Total transferred file size: 36257698208 bytes
Literal data: 36257698208 bytes
Matched data: 0 bytes
File list size: 183217
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 36262755009
Total bytes received: 207851
sent 36262755009 bytes received 207851 bytes 52064555.43 bytes/sec
total size is 36257698208 speedup is 1.00
real 11m36.337s
user 7m48.121s
sys 8m34.168s
# mkreiser4 /dev/sda1
mkreiser4 1.0.7
Copyright (C) 2001-2005 by Hans Reiser, licensing governed by
reiser4progs/COPYING.
Block size 4096 will be used.
Linux 2.6.32-5-amd64 is detected.
Uuid 9140089f-c84d-41b6-8cd0-395e53635c4b will be used.
Reiser4 is going to be created on /dev/sda1.
(Yes/No): Yes
Creating reiser4 on /dev/sda1 ... done
mount /dev/sda1 /mnt
# mount /dev/sda1 /mnt
mount: unknown filesystem type 'reiser4'
# mkreiserfs /dev/sda1;mount /dev/sda1 /mnt;time rsync -a --stats /dcim/ /mnt/
mkreiserfs 3.6.21 (2009 www.namesys.com)
A pair of credits:
Lycos Europe (www.lycos-europe.com) had a support contract with us that
consistently came in just when we would otherwise have missed payroll, and that
they kept doubling every year. Much thanks to them.
Nikita Danilov wrote most of the core balancing code, plugin infrastructure,
and directory code. He steadily worked long hours, and is the reason so much of
the Reiser4 plugin infrastructure is well abstracted in its details. The carry
function, and the use of non-recursive balancing, are his idea.
Guessing about desired format.. Kernel 2.6.32-5-amd64 is running.
Format 3.6 with standard journal
Count of blocks on the device: 488378368
Number of blocks consumed by mkreiserfs formatting process: 23116
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: 3792341e-4405-4743-bf92-7e66e94672e3
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
ALL DATA WILL BE LOST ON '/dev/sda1'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok
ReiserFS is successfully created on /dev/sda1.
Number of files: 11096
Number of files transferred: 10897
Total file size: 36257698208 bytes
Total transferred file size: 36257698208 bytes
Literal data: 36257698208 bytes
Matched data: 0 bytes
File list size: 183217
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 36262755009
Total bytes received: 207851
sent 36262755009 bytes received 207851 bytes 44852149.49 bytes/sec
total size is 36257698208 speedup is 1.00
real 13m28.466s
user 8m1.522s
sys 11m7.198s
Chouette la nouvelle interface de publication de Linuxfr ! :-)
# Facile
Posté par Sufflope (site web personnel) . Évalué à 9.
Facile : Reiser3 est « en fin de vie » (inadapté au matériel de notre époque et vaguement maintenu), Reiser4 est comme la relation de couple entre Hans Reiser et sa femme, jamais compris par quelqu'un d'autre qu'Hans Reiser lui-même.
Reiser (le FS) est aussi mort que Reiser (la femme), et j'arrête l'humour mortifère, et si pour toi les perfs brutes sont plus importantes que la sécurité, la maintenabilité, etc., écris directement sur tes périphs en mode block.
[^] # Re: Facile
Posté par Sufflope (site web personnel) . Évalué à 10.
Vu que la note de mon commentaire baisse je vais rajouter une couche (oui je sais c'est un appeau à moiinssage mais j'assume) :
sans aucune discrimination vis-à-vis de ses erreurs privées (vous voyez de quel cadavre je parle) ; pendant des années Reiser4 s'est fait refouler par des mecs pas très doués genre Linus Torvalds, GKH (j'avoue ne pas savoir écrire son nom)... des types pas hyper techniques quoi.
Maintenant si t'as envie d'utiliser un FS qui s'est fait refouler par les meilleurs programmeurs du monde parce que c'est une merde incompréhensible, je me répète, c'est toi qui valorise tes données, et au pire c'est toi qui seras responsable devant ton patron, pas moi (« mais M. peu importe mon contrat, sur DLFP j'ai vu un benchmark où Reiser4 allait plus vite »).
[^] # Re: Facile
Posté par Anonyme . Évalué à 10.
Va dire ça à mon disque dur acheté l’année dernière.
[^] # Re: Facile
Posté par Frédéric Heulin . Évalué à 10.
Je t'ai pertinenté rien que pour l'ironie de ton pseudo face à ton commentaire …
~~>[ ]
[^] # Re: Facile
Posté par Moogle . Évalué à -5.
Pourtant ReiserFS c'est un filesystem qui tue. Mortel !
# Archivage ?
Posté par Jérôme Pinot (site web personnel) . Évalué à 10.
Hum, tu parles d'archivage et tu compares des vitesses. L'archivage correspond en général à des données peu voire non modifiées que tu souhaites conserver longtemps. Dans ce cas, c'est certainement plus la fiabilité que la rapidité qu'il faudrait comparer.
[^] # Re: Archivage ?
Posté par Maclag . Évalué à 6.
Non non non, c'est un tout nouveau concept révolutionnaire d'archivage en temps réel:
On archive toutes les données enregistrées au fur-et-à-mesure de leur enregistrement, et on synchronise aussi en temps réel: modifications, suppressions, etc.
Et là, les performances prennent tout leur sens.
La semaine prochaine, nous ferons un benchmark sur les FS de travail sur lesquels on ne travaille que par snapshots à intervalles réguliers.
[^] # Re: Archivage ?
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 1.
zfs !
Proverbe Alien : Sauvez la terre ? Mangez des humains !
# attention au paramèérage
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Il ne faut pas oublier que le fsck de reiserfs ne fait quasiment rien.
Les ext3/4 ont une journalisation de donnés très couteuse par défaut qu'il est possible de restreindre aux meta-donnés (comme reiderfs ?).
Il existe une option sur les derniers kernel linux qui aligne les blocs de 4ko sur des plus grosses zones (64 ko est recommandé) mais sur des gros fichiers, il faudrait tester avec des blocs de 1 à 4 Mo. Les différences de performances peuvent alors devenir énorme.
"La première sécurité est la liberté"
[^] # Re: attention au paramèérage
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"in fstab:
noatime,journal_async_commit,data=writeback,barrier=0,nobh,commit=60,errors=remount-ro
in menu.lst:
rootflags=data=writeback,commit=60,nobh,barrier=0,journal_async_commit"
https://bbs.archlinux.org/viewtopic.php?pid=622697#p622697
"La première sécurité est la liberté"
[^] # Re: attention au paramétrage
Posté par Patrick Trauquesègues . Évalué à 1.
Merci pour cette réponse.
Le fait qu'on puisse régler à postériori son fonctionnement devrait me permettre de peaufiner les réglages à l'usage, ce que je n'avais jamais pris la peine de faire pensant que les réglages par défaut devaient me convenir, et que je risquerais plus de le détraquer qu'autre chose.
J'étais parti du principe qu'un FS qui fait la même chose en plus vite est forcément plus efficace. Par efficace j'entends qu'il consomme moins de ressources. Ce n'est pas forcément le cas qu'ils fassent la même chose, toutefois je n'ai pas eu les explications claires que j'attendais sur ce point.
Quant à la fiabilité de l'un ou de l'autre, je n'ai pas bien compris quels en étaient les critères de détermination.
J'ai tendance, faute de mieux, à faire mon opinion au bruit que fait le disque dur et surtout à sa longévité. Or le disque que je remplace, avait à peine un an, ce qui ne m'étais jamais arrivé, et était surtout le premier sur lequel j'utilisais ext4 pour les grosses partitions et qui tournait nuit et jour. Bien heureusement je retrouvais les données dupliquées sur une vieille partition reiserfs... Certes, le hasard, rien ne dit que le disque était de bonne facture, et je suppose que ceux qui préconisent ext4 ne remplacent pas leurs disques tous les ans.
[^] # Re: attention au paramétrage
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
La structure de reiserfs rend une corruption de données problématique. C'est moins le cas sur ext* et btrfs. De plus l'outil fsck est loin d'être efficace dans le cas de reiserfs (il n'a jamais été fini).
Sur un FS, il y a plusieurs choses qui peuvent réduire les performances :
* La journalisation, et il existe plusieurs niveau (data, ou meta-data)
* L'utilisation de "barrières IDE" qui s'assure que les données sont réellement écrites sur disque
* L'asynchronisme de l'écriture du journal qui peut entrainer des fichiers vides en cas de crash (xfs)
* la taille des blocs de base (pour ne pas perdre de temps sur le déplacement des têtes de lectures)
* La structure sur disque : reiserfs était connu pour être efficace sur les petits fichiers, mais il me semble que ext4 utilise une astuce similaire.
* le (no)atime issue de posix (data d'accès au fichier, où chaque lecture entraine une écriture)
"La première sécurité est la liberté"
[^] # Re: attention au paramétrage
Posté par barmic . Évalué à 3.
Le plus simple pour tester c'est de ce créer des partitions virtuelles, pour ça rien de plus simple :
Et te voila avec un disque dur virtuel d'1 Gio accessible via dev/loopX (X un numéro).
Tu format avec mkfs/parted/fdisk/whatever. Puis tu peu la monter pour ajouter des fichiers dedans.
Ensuite pour tester de la corruption, tu la démonte (je sais pas s'il faut aussi virer la connexion avec la losetup) et tu écris sur quelques octets dedans avec quelque chose qui doit ressembler à :
Devrait bousiller 10 o à 550*10 octets du début de la partition.
Tu regarde ce que ça donne quand tu la remonte et avec un fsck.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.