Pourquoi les transferts de fichiers en réseau sont-ils si lents avec plusieurs petits fichiers ?

Métadonnées du système de fichiers. La surcharge nécessaire pour rendre les fichiers possibles est sous-estimée par les administrateurs système. Jusqu'à ce qu'ils essaient de gérer de nombreux petits fichiers.

Supposons que vous ayez un million de petits fichiers de 4 Ko, un stockage relativement rapide avec 8 broches de disque, et un lien de 10 Go que la matrice peut parfois saturer avec des lectures séquentielles. Supposons également 100 IOPS par broche, et qu'il faut une IO par fichier (c'est une simplification excessive, mais cela illustre bien le propos).

$ units "1e6 / (8 * 100 per sec)" "sec"
        * 1250
        / 0.0008

21 minutes ! Supposons plutôt que le million de fichiers soit dans un seul fichier d'archive, et que le transfert séquentiel puisse saturer la liaison de 10 Gb. 80% de débit utile, du fait d'être enveloppé d'IP dans Ethernet.

$ units "(1e6 * 4 * 1024 * 8 bits) / (1e10 bits per second * .8)" "sec"
        * 4.096
        / 0.24414062

4 secondes, c'est un peu plus rapide.

Si le stockage sous-jacent est constitué de petits fichiers, n'importe quel protocole de transfert de fichiers aura un problème avec un grand nombre d'entre eux. Lorsque les IOPS de la matrice sont le goulot d'étranglement, le protocole du serveur de fichiers qui s'y ajoute n'est pas vraiment utile.

Le plus rapide serait de copier une grande archive ou une image disque. Principalement des entrées-sorties séquentielles, moins de métadonnées du système de fichiers.

Peut-être qu'avec les protocoles de service de fichiers, il n'est pas nécessaire de tout copier. Montez le partage distant et accédez aux fichiers dont vous avez besoin. Cependant, accéder à des répertoires contenant un très grand nombre de fichiers, ou les copier tous, est toujours lent (et attention, les serveurs NFS qui s'éteignent inopinément peuvent faire que les clients restent bloqués en IO pour toujours).