Aller au contenu

Ubuntu - Disque Dur avec haute latence et débit chutant.


Sujets conseillés

Posté

Salut tout le monde !
Je viens vers vous car je suis face à un souci qui me préoccupe assez bien.
J'avais mon Ubuntu desktop qui était installé sur un SSD de 120GB.
Ce disque devenant trop petit avec le temps, j'ai migré le tout sur un nouveau SSD de 480GB.
J'ai durant cette manipulation du virer la swap pour agrandir le root pour ensuite refaire une swap à la fin e l'espace disque.
J'ai corrigé l'uuid de la swap dans mon fstab mais depuis, je me retrouve avec une latence d'accès à ce disque pouvant aller à 50ms, ce qui est énorme et ralenti tout de manière considérable.

Je me suis alors dit que le disque devait avoir un souci même si il était neuf.
J'ai pris la décision de backup mon Win7 qui est sur un autre SSD de 500GB dans ce même PC avec un petit dd.
Le backup démarre très bien sauf que mon débit chute petit à petit pour partir de 45MB/s à maintenant 2,2MB/s après 176GB de copie.
J'ai essayé aussi avec l'outil graphique d'Ubuntu, même problème...

Du coup, je ne suis pas capable de tester mon Ubuntu sur ce disque vu que je ne suis pas capable de faire le backup de ce disque afin de le libérer du Win7 dessus.
Et là, face à tous ces événements assez étranges, je me demandais si vous auriez une idée ?
Pcq un dd qui démarre super bien et baisse en débit progressivement sur des heures tel la vitesse d'Apollo 11 s'éloignant de la Terre, je ne cerne pas...
Et pour cette latence élevée sur mon SSD Ubuntu, je pense fortement à un défaut de conception.

Merci d'avance pour votre aide !

Posté

Ce disque de 480GB a été partitionné comment ?

Que donne un "fdisk -l" ?

Posté

Ceci 😉

Disque /dev/sda : 447,1 GiB, 480103981056 octets, 937703088 secteurs
Disk model: SH00R480GB      
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x5d2c6d6b

Périphérique Amorçage     Début       Fin  Secteurs Taille Id Type
/dev/sda1    *             2048 926449663 926447616 441,8G 83 Linux
/dev/sda2             926449664 937701375  11251712   5,4G 82 partition d'échange Linux / Solaris

Comme c'est un PC de Bureau, j'ai tout mis dans la même partition 😉

Posté

Par contre, quand je fais la copie de mon Samsung SSD EVO 500GB vers un disque dur mécanique de 640GB dans le PC et connecté en sata, j'ai aussi une chute de vitesse de transfert qui avec le temps tombe à 2MB/sec alors que tout démarre à plus de 40MB/sec
C'est à ne rien comprendre 😕
J'ai déjà fait plein de copies par le passé avec dd et jamais j'ai croisé un tel cas.
Comme si il y avait un goulot d'étranglement qui se resserrait petit à petit avec le temps.

Posté

40MB/sec c'est le temps que le cache du disque se remplisse, non ?

Même cela ne me semble pas performant.

 

Que donne hdparm comme résultat pour tes disques ?

 

Pour lever le doute, essaie en remplaçant le câble SATA !

 

 

 

Posté

Silence radio depuis mardi ?

Que donne le "hdparm" ? Tu as eu l'occasion de tester un nouveau câble SATA ?

 

 

Posté

Alors le hdparm donne ceci

/dev/sda:
 multcount     =  1 (on)
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 58369/255/63, sectors = 937703088, start = 0

et j'ai changé par trois fois la câble Sata.

Posté

et "hdparm -t -T /dev/sda" donne quoi ?

 

Chez moi ça donne (avec du SSD NVMe, c'est une bête de course) :

# hdparm -t -T /dev/md5

/dev/md5:
 Timing cached reads:   36604 MB in  1.99 seconds = 18413.17 MB/sec
 Timing buffered disk reads: 4612 MB in  3.00 seconds = 1537.12 MB/sec

 

Posté

Quelque chose qui est moins rapide
 

/dev/sda:
 Timing cached reads:   16390 MB in  1.99 seconds = 8223.20 MB/sec
 Timing buffered disk reads: 436 MB in  3.02 seconds = 144.47 MB/sec

 

Posté

Le taux de transfert d'un disque varie aussi très largement selon la taille des fichiers transférés et le niveau de fragmentation du disque source.

 

Et si la destination a des bad blocks, il y aura pas mal de retries !

 

Donc, le mieux serait de scanner le disque en profondeur avant de créer un filesystem. Je pense qu'Ubuntu a un utilitaire nommé "badblocks" qui fait ça !

 

<edit: http://manpages.ubuntu.com/manpages/bionic/fr/man8/badblocks.8.html >

 

 

 

Posté

J'ai formaté mon disque dur de 640 GB qui prenait les backup en Ext4 et plus en NTFS et maintenant, je n'ai plus aucun souci...
A croire que la gestion du NTFS sous Linux n'est pas optimale.

Posté
Il y a 7 heures, Gecko64 a dit :

A croire que la gestion du NTFS sous Linux n'est pas optimale.

Comme depuis le début tu nous parles d'un système sous Ubuntu et d'utilisation de "dd" ... je n'ai à aucun moment pensé que tu pouvais avoir formaté ton disque en NTFS !

 

 

Posté

Ben j'ai aussi tenté le backup sur un NAS et ça ramait aussi mais ça, je pense que c'est mon QNAP qui pose souci.
Oui et puis je n'ai plus pensé que je l'avais laissé en NTFS pour aussi pouvoir y accéder quand je démarrais mon Win7, que je n'utilise plus maintenant.
Enfin, une bonne nouvelle, je vais pouvoir migrer mon système :D

Merci pour ton aide, une bonne journée ! 😉

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...