Transfert USB 35.000 entité de fichiers. Transfer lent !

[CasualMint]

Bonjour.

Je recherche un solution pour amélioré la vitesse de copie sur une clé usb. J'ai un fichier qui détiens environ 35.000 fichier léger (5k~~)
Le dossier en lui même n'est pas lourd mais au vue du nombre de fichier la copie est lente.

Comment amélioré le transfert ? Peut-être avec en l'archivant au préalable... Mais quel type d'extension pour l'archive ?

De plus ma clé usb est bas de gamme en qualité. Elle doit avoir une moyenne de 4~5Mo en écriture !

[jjcojax]

Bonjour,

Un avis,

Le contrôleur d'une clé USB n'a pas de mémoire cache comme un disque pour préparer au mieux l'écriture dans ta clé USB

Si tu fais un test de performance en écriture avec le programme disks (disques si ta distribution est en Français) tu remarquera qu"au plus les fichiers sont petits, au plus c'est lent, et surtout en écriture (le test peut te faire des fichiers de 1 MB, 10 MB, 100 MB ou 1 GB )

Si c'est une clé USB2 1er prix (par exemple Philips snow 32 GB) et que tu enregistres 1000 fichiers de 1 MB, la vitesse sera au mieux à 300 KB par secondes.
Puisque tu indiques que ce sont des fichiers encore plus petit, ce sera pire.

Soit tu sais te faire des zips (archive) avant, pour passer des fichiers plus gros (entre 500 MB et 1 GB) (je n'ai pas un choix à te proposer, tu choisis ce que ta distribution propose)

Soit tu achètes un adaptateur en USB3 dans lequel tu introduits des cartes micro SD (classe 10)

Soit tu achètes une bonne clé USB3 (car il y a du brol) en sachant que celle prévue pour ReadyBoost sont vraiment supérieures (proche de la qualité SSD)

Et qu'un vrais SSD en USB est devenu une solution abordable.

jjcojax

[CasualMint]

Exactement !

J'avais une valeur moyenne de transfert de 45k/s pour 250Mo au total et 45.000 fichier de 4k à 25k.
Ça m'avais pris 45mn
J'ai tout compresser en tar.xz et j'ai divisé par six le poids. La copie c'est effectuer en 2mn.

[Shiva]

Exactement !

J'avais une valeur moyenne de transfert de 45k/s pour 250Mo au total et 45.000 fichier de 4k à 25k.
Ça m'avais pris 45mn
J'ai tout compresser en tar.xz et j'ai divisé par six le poids. La copie c'est effectuer en 2mn.

Pour être honnête, il faudrait rajouter le temps de la création de l'archive compressée à la copie pour comparer.

En plus, les choses ne sont pas si simples et perdre 45 mn la première fois qu'on pourra éventuellement (en fonction du type de données qu'on traite) regagner avec bénéfice au cours du temps peut aussi s'envisager.

Si tar fait partie intégrante d'une stratégie de backup ou de transfert de fichiers, il a été conçu à l'origine pour des sauvegardes sur bandes magnétiques, d'où son nom (Tape ARchiver). Ce n'est pas qu'une simple anecdote historique : l'accès à une sauvegarde tar (un tarball) est resté séquentiel, c'est-à-dire que pour accéder au 125ème fichier d'un tarball, il faut lire les 124 qui précèdent, contrairement à un système de fichiers indexé (comme ext4 ou NTFS) où il y a une table d'adressage qui indique directement où se trouve le 125ème fichier.

Cela implique que d'une part la décompression ciblée d'un fichier sera d'autant plus longue qu'il est situé vers la fin et que la mise à jour d'un fichier dans un tarball se fait en rajoutant la nouvelle version à la fin de l'archive et que ce fichier va, lors de la décompression, être copié autant de fois qu'il est présent dans le tarball, les écrasements successifs permettant de s'assurer que c'est la dernière version qui est active. Si on compare avec un cp -u qui ne copie que les fichiers modifiés ou absents, on mesure la perte d'efficacité. Certes, tar a une option --delete qui permet d'effacer un fichier dans une archive, mais ça n'a rien à voir avec un mv ou un rm appliqué sur un fichier standard : pour effacer un fichier dans un tarball, toute l'archive doit être reconstruite.

En bref, tar reste intéressant pour sauvegarder un "état" complet et figé de quelque chose (comme une installation). Pour illustrer par un exemple, lorsque le Gestionnaire de mises à jour m'informe qu'une nouvelle version de Firefox est dans les tuyaux, mon premier réflexe n'est pas d'installer la mise à jour (ça c'est le second), mais de créer un tarball de ~/.mozilla/firefox. Si quelque chose se passe mal, du type incompatibilité entre les versions (ça m'est déjà arrivé), je ne perds pas mes marque-pages, mes préférences, mes profils, etc... De plus, transféré et décompressé sur un autre PC, il me permet de cloner toute ma configuration Firefox sans passer par l'usine à gaz de Mozilla.

Enfin, lors de la décompression, il faut vérifier qu'une version plus récente des fichiers n'existe pas sur la destination (par exemple, si j'ai modifié un fichier sur mon PC de bureau après que l'archive ait été crée sur mon portable, ces modifications seront perdues si l'option --keep-newer-file n'est pas activée (le Actions / Ajouter uniquement si plus récent du Gestionnaire d'archives).

Par contre, tar n'est pas très intéressant pour conserver un ensemble de fichiers qui est régulièrement modifié, mais de façon minime (un répertoire de configuration ou de documents textes). Pour cela, les commandes cp -u ou rsync sont bien plus efficaces. Et si l'on n'est pas familier avec le scripting bash, il y a FreeFileSync qui fait ça très bien.

[Shiva]

Enfin, lors de la décompression, il faut vérifier qu'une version plus récente des fichiers n'existe pas sur la destination (par exemple, si j'ai modifié un fichier sur mon PC de bureau après que l'archive ait été crée sur mon portable, ces modifications seront perdues si l'option --keep-newer-file n'est pas activée (le Actions / Ajouter uniquement si plus récent du Gestionnaire d'archives).

Correction. Ça, c'est pour la mise à jour d'une archive. La case à cocher est Ne pas écraser les fichiers plus récents.