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)
[^] # Re: attention au paramétrage
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pour l'archivage : reiserfs ou ext4 ?. É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é"