URL: https://linuxfr.org/users/patrick32/journaux/pour-l-archivage-reiserfs-ou-ext4 Title: Pour l'archivage : reiserfs ou ext4 ? Authors: Patrick Trauquesègues Date: 2012年02月06日T00:21:00+01:00 License: CC By-SA Tags: vidéo, benchmark, reiserfs, ext4, btrfs, archivage et photo Score: 3 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 ! :-)