10.11 El Capitan Copies lentes, mais vraiment lentes

[magicPDF]

Bonjour

La question est dans le titre et dans les captures ci-dessous.
Les données sont dans un disque-dur LaCie 500 Go formaté en ExFat et connecté en Firewire 400, et je dois les copier sur un disque-dur externe de 500 Go formaté en ExFAT lui aussi et connecté en USB-2.
Ce sont surtout des photos, des vidéos et des fichiers de travail iMovie et Premiere.

J'ai coché l'option "Dossier partagé" pour chaque disque, j'ai essayé avec les deux ports USB du Mac car je crois savoir que certains MacBook Pro ont de l'USB-1 sur un des cotés mais ça n'y change rien.
J'ai redémarré l'ordi, déconnecté et reconnecté les DD plusieurs fois.
J'ai l'impression que chaque copie est plus lente que la précédente.

Je viens de tester avec un fichier de 22 Mo : il a fallu plus de cinq minutes chrono pour le copier. Tout seul et sans que l'ordi ne fasse rien d'autre en même temps.

Que se passe-t-il ?
Que puis-je faire pour accélérer la copie ?

Merci.

​

 

[ericse]

Bonjour,
Il faudrait que tu détermine si c'est la lecture depuis le 1er disque qui est lente, ou l'écriture sur le second, ça permettrait de cibler la solution. Tu as un peu de place sur le disque interne pour y copier quelques fichiers ?

 

[edenpulse]

Des disques durs, en USB-2, plein de petits fichiers... juste 4 Go de RAM.... ça va prendre un paquet de temps c'est certain.
Tu peux toujours tester avec un logiciel comme BlackMagic Disk Speed Test, ça te donnera des infos.

 

[magicPDF]

Il faudrait que tu détermine si c'est la lecture depuis le 1er disque qui est lente, ou l'écriture sur le second,

J'ai testé les deux en lecture-écriture, c'est inhabituellement lent.
Le disque USB fonctionne très bien sur le PC en USB-3 mais connecté au Mac il est aussi lent que le disque FW.

es disques durs, en USB-2, plein de petits fichiers... juste 4 Go de RAM

Ça fait une bonne dizaine d'années que j'utilise ce Mac et je n'avais jamais vu ça, pourtant j'en ai fait des copies !

 

[ericse]

J'ai testé les deux en lecture-écriture, c'est inhabituellement lent.
Le disque USB fonctionne très bien sur le PC en USB-3 mais connecté au Mac il est aussi lent que le disque FW.

Ok, peut être que des copies d'écran de Blackmagic Test comme le propose @edenpulse aideraient à comprendre

 

[magicPDF]

Je ne peux pas installer Blackmagic test et la recherche de l'App Store ne me propose rien d'équivalent.

J'espérais une solution évidente à un truc que j'aurais raté mais ce n'est pas grave, mon vieux Mac n'a que ça à faire.
Qui va lentement va surement !

Merci à tous.

 

[Membre supprimé 1060554]

Bonjour magicPDF

Essaie : ☞AJA System Test Lite☜.

 

[magicPDF]

Essaie : ☞AJA System Test Lite

Merci.
Grâce à lui j'ai vu que c'est le disque USB qui ne fonctionnait pas correctement.

Renseignement pris c'est bien ce que je pensais, j'avais raté un truc : je l'avais formaté avec Utilitaire Disque en ExFAT avec l'option "Enregistrement de démarrage principale MBR".
Alors qu'il faut utiliser l'option "Table de partition GUID" si on veut pouvoir utiliser des fichiers de plus de 2 Go.
Voir : https://www.agnosys.com/bien-formater-un-support-de-stockage/

Je l'ai reformaté et maintenant j'ai des vitesses de copie normales.
:zen:

 

[Membre supprimé 1060554]

Content pour toi !

----------

Ton remplacement de la table de partition MBR par une GPT tout en conservant le format exFAT du volume > remplacement de table ayant un effet sur la vitesse de copie à destination du volume exFAT --> équivaut pour moi à une "première" - expérimentalement parlant. Car j'avais le double a priori suivant :

- a) dès lors que le disque (HDD > DDE > clé USB) est susceptible de porter un volume démarrable par Mac => alors une table GPT est requise au lieu d'une MBR. Car la table GPT est lue par le programme de boot primaire du Mac (l'EFI de la carte-mère) > pour récupérer l'adresse à la partition du volume à démarrer. Programme EFI requérant un encodage GPT des descripteurs de partitions > et pas un encodage MBR pour ce faire.​

​

- b) mais si le disque considéré est voué à une fonction de stockage (et pas de démarrage) => alors la table de partition générale de l'en-tête du disque n'aurait pas d'incidence sur les opérations de fichiers (de type copie) à destination du volume. Car le programme EFI primaire ne serait pas impliqué en mode démarrage. Mais le volume exFAT se trouverait monté comme appareil par le kernel (le moteur de l'OS démarré) > et par suite directement adressable pour des opérations d'applications sans passage requis par la table de partition du disque.​

De ce double a priori --> j'aurais déduit logiquement que la vitesse de copie à destination du volume exFAT devait être égale quelle que soit la table de partition. Le fait expérimental dont tu attestes contredit cette "théorie". En somme : il y aurait une différence > en ce qui concerne un disque de stockage --> entre la façon dont le kernel de macOS (ou d'OS X) monte le volume d'une partition décrite en mode MBR ou le volume d'une partition décrite en mode GPT > même si le format de ce volume est le même (exFAT) dans les 2 cas. Différence de montage qui aurait une incidence pratique sur la vitesse d'une copie de fichiers. Je ne sais quoi penser (= "conjecturer théoriquement") pour rendre raison de ce fait expérimental.

 

[ericse]

Je l'ai reformaté et maintenant j'ai des vitesses de copie normales.

Content que cela fonctionne, mais je soupçonne qu'il s'agisse plus d'une corrélation que d'une causalité (la méprise est malheureusement facile, comme le disent les Cigognes )

 

[magicPDF]

Ton remplacement de la table de partition MBR par une GPT tout en conservant le format exFAT du volume > remplacement de table ayant un effet sur la vitesse de copie à destination du volume exFAT --> équivaut pour moi à une "première" - expérimentalement parlant. Car j'avais le double a priori suivant :

Je n'ai pas tout compris. o_O
Les disques sont en ExFAT car ce sont les données d'une personne décédée brutalement et je voudrais que quand elle sera plus grande sa fille puisse les récupérer sur l'ordinateur (du futur, Mac, PC ou autre) qu'elle aura à ce moment là.

Sur la page que j'ai donnée en lien il est expliqué que "Enregistrement de démarrage principal MBR" ne supporte pas les fichiers de plus de 2 Go. Contrairement à "Table de partition GUID". Alors je n'ai pas cherché plus loin parce que pour moi ça expliquait le fait que la copie démarrait à vitesse normale avant de se mettre à patiner dans la semoule quelques minutes plus tard, puisque j'ai supposé que ça se produisait dès que la copie rencontrait un fichier de plus de 2 Go.

Corrélation ou causalité ?
C'est une bonne question.

 

[Membre supprimé 1060554]

Sur la page que j'ai donnée en lien il est expliqué que "Enregistrement de démarrage principal MBR" ne supporte pas les fichiers de plus de 2 Go. Contrairement à "Table de partition GUID".

Tu as fait une erreur de lecture que je t'explique ci-dessous -->

- a) une table de partition est un dispositif logiciel inscrit sur les blocs de tête d'un disque (l'unique bloc n°0 ou 1er bloc pour une MBR > les blocs n°1 => 33 pour une GPT). La table de partition gère l'espace total du disque découpé a priori en blocs (de 512 octets par défaut) > en y définissant des partitions d'un type particulier. Ces partitions ne sont pas inscrites matériellement sur les blocs du disque > mais virtuellement : il s'agit d'un découpage logique (théorique) > qui permet au kernel (le moteur de l'OS démarré) de construire des "devices" : des appareils logiques de partitions dont tel n° de bloc est le bloc de départ et telle quantité de blocs l'extension. Les "silos" de l'article que tu as cité sont des images constituant un "obstacle épistémologique" (comme disait Bachelard). Les partitions ne sont pas des silos "en dur" matériellement existants sur le disque. Ce sont des découpages virtuels destinés à l'usage de processus moteurs comme l'EFI ou le kernel.​

​

- la limitation classique d'une table MBR est qu'elle ne peut pas gérer plus de 2,2 To de blocs sur un disque. À supposer un disque de 3 To > 800 Go échapperont à sa capacité de gestion. Dans l'article que tu as cité > l'auteur réduit même cette capacité de gestion à 2 To (ce qui n'est pas exact). Une table GPT ne connaît pas cette limitation.​

​

----------​

​

- b) un format de volume est le résultat d'un système de fichiers (filesystem) = dispositif logiciel inscrit matériellement sur les blocs de tête d'une partition logique de disque. Le système de fichiers formate l'espace de blocs d'une partition au sens où il forme en volume cet espace. Un volume étant la conversion d'une extension de blocs bruts d'une partition en espace affichant des fichiers adressables par des applications. Le format d'un volume renvoie au type de système de fichiers formateur : différence entre FAT-32 ou exFAT dans la famille des systèmes de fichiers Windows > différence entre jhfs+ et afps dans celle des systèmes de fichiers Apple.​

​

- la limitation classique en ce qui concerne la capacité de réception de fichiers d'un volume est celle du format FAT-32 > qui ne supporte pas de copie de fichiers supérieurs individuellement à 4 Go. L'exFAT est libre de cette limitation comme les formats Apple.​

​

----------​

Si je résume : en parcourant l'article que tu as cité > tu as lu : "limitation à 2 Go de gestion de fichiers due à une table MBR" comme s'il s'agissait d'une limitation de taille de fichiers à la copie > alors qu'il disait : "limitation à 2 To de gestion de blocs sur un disque de la part d'une table MBR". Comme je le pensais d'entrée > la table de partition d'un disque n'a pas d'effet sur les transactions de fichiers adressées à un volume > mais c'est le type de système de fichiers formateur qui est responsable de la "qualité" du volume.

• comment se fait-il alors que ton erreur de lecture : 2 Go de copie de fichiers au lieu de 2 To de gestion de blocs => ait produit un résultat positif ? --> hé ! parce que passer d'une table MBR à une table GPT a impliqué une réinitialisation du disque entier > et par là un reformatage du volume exFAT. Allons ! --> il y a tout à parier que le système de fichiers formateur du volume exFAT primitif recelait des erreurs qui obéraient la copie de fichiers. Le reformatage du volume a supprimé ces erreurs et libéré la copie. Le changement de table (MBR => GPT) n'a pas eu d'impact en soi > c'est le reformatage de l'exFAT (la suppression / recréation du système de fichiers formateur du volume) => qui a tout fait.

 

[magicPDF]

comment se fait-il alors que ton erreur de lecture : 2 Go de copie de fichiers au lieu de 2 To de gestion de blocs => ait produit un résultat positif ? --> hé ! parce que passer d'une table MBR à une table GPT a impliqué une réinitialisation du disque entier > et par là un reformatage du volume exFAT. Allons ! --> il y a tout à parier que le système de fichiers formateur du volume exFAT primitif recelait des erreurs qui obéraient la copie de fichiers. Le reformatage du volume a supprimé ces erreurs et libéré la copie. Le changement de table (MBR => GPT) n'a pas eu d'impact en soi > c'est le reformatage de l'exFAT (la suppression / recréation du système de fichiers formateur du volume) => qui a tout fait.

Tu as certainement raison parce-que depuis je me suis rendu compte que le disque FireWire est formaté en MBR et il fonctionne très bien avec des fichiers de plus de 2 Go.

ericse avait donc soupçonné juste : corrélation.