Quel est le système de fichiers Linux le plus performant pour stocker beaucoup de petits fichiers (disque dur, pas SSD)?

43

J'ai une arborescence de répertoires qui contient de nombreux petits fichiers et un petit nombre de fichiers plus volumineux. La taille moyenne d'un fichier est d'environ 1 kilo-octet. Il y a 210158 fichiers et répertoires dans l'arborescence (ce nombre a été obtenu en cours d'exécution find | wc -l).

Un petit pourcentage de fichiers est ajouté / supprimé / réécrit plusieurs fois par semaine. Ceci s’applique aux petits fichiers, ainsi qu’aux (petits) fichiers plus volumineux.

Les systèmes de fichiers que j'ai essayés (ext4, btrfs) ont quelques problèmes avec le positionnement des fichiers sur le disque. Sur une période plus longue, les positions physiques des fichiers sur le disque (média en rotation, pas disque à l'état solide) deviennent plus aléatoires. La conséquence négative de cette distribution aléatoire est que le système de fichiers devient plus lent (par exemple: 4 fois plus lent qu'un nouveau système de fichiers).

Existe-t-il un système de fichiers Linux (ou une méthode de maintenance du système de fichiers) qui ne souffre pas de cette dégradation des performances et qui est capable de maintenir un profil de performances stable sur un support en rotation? Le système de fichiers peut fonctionner sur Fuse, mais il doit être fiable.

linux filesystems performance

Si vous savez quels fichiers vont être volumineux / ne changeront pas très souvent, et lesquels seront petits / changeant fréquemment, vous pouvez créer deux systèmes de fichiers avec des options différentes, plus adaptées à chaque scénario. Si vous avez besoin qu'ils soient accessibles car ils faisaient partie de la même structure, vous pouvez faire quelques astuces avec mount, des liens symboliques.

— Marcin

Je suis tout à fait surpris de savoir que btrfs (avec la fonction de copie sur écriture) vous a été lent au fil des ans. Je suis curieux de partager les résultats avec vous, éventuellement de s’entraider dans le nouveau sens de l’ajustement des performances.

— Nikhil Mulley

il y a un nouvel animal zfs en ligne sous Linux, disponible en mode natif et avec des implémentations de fusibles, au cas où vous vouliez jeter un coup d'œil.

— Nikhil Mulley

J'ai essayé zfs sur linux une fois, c'était assez instable. Géré pour verrouiller complètement le système de fichiers assez souvent. Box fonctionnerait, mais tout accès au FS serait bloqué.

— Patrick

Poste similaire serverfault.com/questions/6711/…

— Nikhil Mulley

47

Performance

J'ai écrit un petit repère ( source ) pour savoir quel système de fichiers fonctionnait le mieux avec des centaines de milliers de petits fichiers:

créer 300000 fichiers (512B à 1536B) avec les données de / dev / urandom
réécrire 30000 fichiers aléatoires et changer la taille
lire 30000 fichiers séquentiels
lire 30000 fichiers aléatoires
supprimer tous les fichiers
synchroniser et supprimer le cache après chaque étape

Résultats (temps moyen en secondes, inférieur = meilleur):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Résultat:
alors qu'Ext4 affichait de bonnes performances globales, ReiserFS lisait extrêmement vite des fichiers séquentiels. Il s'est avéré que XFS est lent avec de nombreux petits fichiers - vous ne devriez pas l'utiliser pour ce cas d'utilisation.

Problème de fragmentation

Le seul moyen d'empêcher les systèmes de fichiers de distribuer des fichiers sur le lecteur est de conserver la partition aussi grande que nécessaire, tout en veillant à ne pas la rendre trop petite pour éviter la fragmentation entre fichiers. Utiliser LVM peut être très utile.

Lectures complémentaires

Arch Wiki contient d'excellents articles sur les performances du système de fichiers:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

— taffer
source

4

Vous devez spécifier la version du noyau sur laquelle vous basez cette comparaison. XFS a eu quelques améliorations très importantes dans l’un des noyaux récents (je pense que c’était 2.6.31, mais ne me citez pas dessus).

— Patrick

1

btrfs en interne fait votre tour de LVM. Il alloue des morceaux plus petits du disque et place les fichiers dans ces morceaux, puis n'alloue un autre morceau du disque que lorsque les morceaux existants se remplissent.

— Psusi

1

Cela est vrai de tout système de fichiers. C'est pourquoi les applications utilisent des choses comme fsync ().

— Psusi

2

@affer, c'est ça. Les transactions ont le même effet que le journal dans les autres systèmes de fichiers: elles protègent les métadonnées de fs. En théorie, elles peuvent être utilisées par les applications de la manière que vous décrivez, mais il n'y a actuellement aucune API permettant aux applications d'ouvrir et de fermer des transactions.

— Psusi

1

@taffer Votre "référence récente" date d'avril 2015, a plus de trois ans et utilise XFS avec seulement les options par défaut. Ceci est une version antérieure à xfsprogs 3.2.3, qui fait de XFS v5 la valeur par défaut et de tous les avantages qu’elle apporte. Il n’a pas non plus été formaté avec -m finobt = 1, qui change la donne pour la performance XFS avec de petits fichiers et de lourdes mises à jour de métadonnées. Non, il n’ya pas de solution miracle, mais il n’est pas sage de fonder votre opinion sur d’anciens points de repère, en particulier lorsque les principales fonctionnalités de modification des performances ont été ignorées, indisponibles ou désactivées.

— Jody Lee Bruchon

7

J'utilise ReiserFS pour cette tâche, il est spécialement conçu pour gérer beaucoup de petits fichiers. Il est facile de lire un texte à ce sujet sur le wiki funtoo.

ReiserFS possède également une multitude de fonctionnalités visant spécifiquement à améliorer les performances des fichiers de petite taille. Contrairement à ext2, ReiserFS n'alloue pas d'espace de stockage dans un ou plusieurs k blocs fixes. Au lieu de cela, il peut allouer la taille exacte dont il a besoin.

— Baarn
source

1

Il existe également des problèmes de stabilité avec ReiserFS. RH et SuSE ont donc abandonné ce système. D'après le principe (basé sur BTree), BTRFS devrait être comparable.

— Nils

6

Les performances ext4 chutent après 1 à 2 millions de fichiers dans un répertoire. Voir cette page http://genomewiki.ucsc.edu/index.php/File_system_performance créé par Hiram Clawson chez UCSC

— Max
source

0

XFS est reconnu pour ses très bonnes performances dans des situations comme celle-ci. C'est en partie pourquoi nous l'utilisons dans mon travail pour nos magasins de courrier (pouvant contenir des centaines de milliers de fichiers dans un seul répertoire). Il a une meilleure tolérance aux pannes que ReiserFS, est utilisé beaucoup plus largement et est généralement un système de fichiers très mature.

De plus, XFS prend en charge la défragmentation en ligne. Bien qu’il utilise une technique d’allocation différée qui entraîne au départ moins de fragmentation (vs autres systèmes de fichiers).

— Patrick
source

20

XFS est reconnu pour ses très bonnes performances dans des situations comme celle-ci. [citation nécessaire]

— taffer

8

Ehm, xfs est particulièrement connu pour le contraire: travailler très bien avec de gros fichiers, mais pas très bien sur de petits fichiers! Regardez ce repère exhaustif par exemple (ou sautez directement à la conclusion de la page 10 ^^): ilsistemista.net/index.php/linux-a-unix/…

— Levite le

1

@ Levit, je pense que vous avez mal interprété ce rapport. Le rapport montre très clairement que XFS fonctionne très bien pour les E / S aléatoires. Mais cela mis à part, le rapport ne traite pas du type de scénario dans cette question, beaucoup de fichiers. Les entrées / sorties aléatoires sont une chose, un grand nombre de fichiers est l'endroit où ext * tombe à la surface.

— Patrick

2

Le seul endroit où XFS est vraiment meilleur il y a les opérations de lecture / écriture aléatoires (il me semble toujours étrange qu'un motif de lecture réellement aléatoire sur un disque mécanique puisse obtenir 10 Mo / s - me semble être une optimisation qui ne vole pas dans le monde réel (à mon humble avis)), alors qu’à la page 7, cela montre exactement ce que j’ai dit plus tôt, XFS est vraiment efficace pour la gestion de gros fichiers! Regardez les pages 3 et 5, en particulier sur 3, vous voyez que le traitement de petits fichiers est clairement différent de celui d’ext! Je n'ai vraiment rien contre XFS cependant, mais d'après ce que vous trouvez un peu partout, ce n'est pas le meilleur optiome pour de nombreux petits fichiers, c'est tout ce que je dis!

— Lévite

5

XFS peut également être extrêmement lent lorsqu'il s'agit de gros fichiers, si ces fichiers sont étendus aléatoirement / lentement avec de petits morceaux sur une longue période. ( syslogdModèle typique .) Par exemple, dans une configuration XFS sur MD que je viens d’observer, la suppression d’un fichier de 1,5 Go a pris 4,75 minutes (!) Alors que le lecteur de disque était limité à 100 transactions / s à un taux d’écriture de plus de 2 Mo / s. Cela a également un impact négatif sur les performances d'autres opérations d'E / S parallèles sur le même lecteur, car le lecteur est déjà saturé. Je n'ai jamais rien vu de tel dans d'autres FS (ou en train d'être testé dans des points de repère).

— Tino