Comment tracer un transfert de fichier distant qui échoue toujours à la même taille de fichier

Un transfert qui échoue de manière répétée au même nombre d'octets atteint généralement une limite déterministe ou une étape post-transfert plutôt qu'une perte de paquets aléatoire.

Pour un NAS distant ou un service de fichiers auto-hébergé, le point d'échec visible peut provenir du système de fichiers de destination, de l'espace libre ou de l'application d'un quota, d'une limite de téléchargement d'application, d'un proxy inverse, d'un compteur client 32 bits, d'une durée de connexion fixe ou du traitement du checksum après l'arrivée de la charge utile. Le diagnostic le plus rapide enregistre le décalage exact en octets et le temps écoulé, puis modifie la taille du fichier, le débit de transfert, le protocole et la destination une variable à la fois.

Enregistrez le décalage exact en octets et la phase d'échec

Effectuez le même transfert deux fois et enregistrez la taille source, les octets transférés, le pourcentage, le temps écoulé, l'erreur client, l'erreur serveur et si un fichier partiel reste. Distinguez l'échec pendant le transfert de la charge utile de l'échec lors du renommage, du checksum, de la validation, de l'indexation ou de la confirmation finale de l'API.

Un cas de support WinSCP échouait systématiquement à 4 Go jusqu'à ce que l'utilisateur identifie une limite de taille de fichier FAT32. La frontière exacte en octets révélait une contrainte de stockage plutôt qu'un problème de routage SFTP ou SCP.

Si le nombre d'octets est identique dans une petite marge, privilégiez les limites fixes et les bornes entières. Si le temps écoulé est identique mais que le nombre d'octets varie avec la vitesse de transfert, privilégiez les délais d'attente de connexion, de proxy, d'inactivité ou d'authentification.

Modifiez la vitesse de transfert pour séparer la taille du temps

Transférez le même fichier une fois via le chemin distant normal et une fois via un chemin délibérément plus lent ou plus rapide. Notez si l'échec suit le même nombre d'octets ou la même durée.

Une discussion sur l'API Dropbox a révélé que des fichiers semblant échouer au-delà de 4 Go pouvaient en fait refléter un délai d'attente HTTP, et a suggéré des téléchargements partiels basés sur des plages pour éviter une requête longue unique.

Lorsque le nombre d'octets change mais que le temps écoulé reste stable, inspectez la durée de vie de la session tunnel, le délai de lecture du proxy, les jetons expirants et la détection d'inactivité. Lorsque l'échec reste à une valeur exacte d'octets malgré un grand changement de vitesse, poursuivez avec les limites du système de fichiers, du quota, du client et de l'application.

Testez plusieurs fichiers autour de la limite suspectée

Créez ou sélectionnez des fichiers juste en dessous, exactement à, et juste au-dessus de la taille échouant. Testez aussi un fichier différent de même taille pour que le contenu, le nom de fichier, la compression et les métadonnées ne deviennent pas des variables cachées.

Un rapport sur le forum FlashFXP décrivait un transfert FTP qui s'arrêtait exactement à 4,00 Go. Les limites en puissances de deux comme 2 Go, 4 Go ou 8 Go indiquent souvent une limite de compteur, de système de fichiers ou d'application.

Si chaque fichier au-dessus du seuil échoue, inspectez les limites strictes. Si un seul fichier échoue, comparez la longueur du chemin, les caractères du nom de fichier, les régions clairsemées, les permissions, les erreurs de lecture source et si le traitement côté serveur traite ce type de fichier différemment.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifiez le système de fichiers de destination, le quota et l'espace temporaire

Identifiez le système de fichiers contenant le fichier final et celui contenant les téléchargements temporaires. Vérifiez la taille maximale des fichiers, les octets libres, les inodes libres, le quota utilisateur, le quota du dataset, la capacité du volume du conteneur et toute partition de staging.

Un service distant peut accepter tout le flux dans un emplacement temporaire et échouer seulement lorsqu'il déplace ou valide le fichier. Cela produit une erreur client proche de 100 % même si le chemin réseau a livré presque tous les octets.

Transférez le même fichier vers un autre partage ou dataset sur le même NAS. Si la limite suit la destination, corrigez son système de fichiers, son quota ou son espace de staging ; si elle suit le client ou le protocole à travers les destinations, poursuivez en dehors de la couche de stockage.

Contournez l'application, le proxy ou le tunnel une couche à la fois

Comparez le flux de travail distant normal avec un test direct du protocole : SFTP au lieu d'un téléchargement web, accès VPN direct au lieu d'un proxy inverse public, ou transfert local LAN au lieu du tunnel distant. Conservez le même stockage source et destination.

Un utilisateur rclone a constaté que de gros téléchargements redémarraient après une longue pause jusqu'à ce qu'il modifie le délai d'attente, tandis que le serveur semblait effectuer un travail de checksum post-téléchargement. Cela illustre pourquoi un échec à la fin du même fichier n'est pas toujours une limite de taille en octets.

Si le SFTP direct réussit alors que le chemin web échoue, inspectez les limites de téléchargement de l'application et du proxy. Si le transfert local réussit mais que chaque protocole distant échoue au même temps écoulé, inspectez le tunnel, le chemin ISP, la durée de vie de la session et les middleboxes.

Validez la correction avec des tests de reprise et de checksum

Après avoir corrigé la limite suspectée, répétez les tests avec des fichiers en dessous et au-dessus de l'ancienne limite. Testez si le protocole reprend un transfert interrompu délibérément et si le hash final du fichier correspond à la source.

Le flux de travail ZimaSpace pour mettre en scène de gros transferts NAS offre une méthode plus sûre pour retester sans redémarrer un travail de plusieurs téraoctets depuis zéro.

Le diagnostic est complet uniquement lorsque l'ancienne limite est franchie à plusieurs reprises, que le serveur valide le fichier, que le checksum correspond et que les journaux identifient la couche corrigée. N'acceptez pas les tentatives automatiques qui masquent un échec déterministe et gaspillent silencieusement la bande passante.