Forum Linux.debian/ubuntu Raid 1 : cp, Freeze et Problème de débit

Posté par electro575 le 15 juin 2026 à 15:59. Licence CC By‑SA.

Étiquettes : aucune

juin

2026

Bonjour à tous,

Je me suis fais un PC avec 6 disques dur en RAID 1, chiffrés luks et au format ext4. Je suis sur une debian Trixie.

Pour ce qui est du TRIM, j'ai l'option de montage "discard" mais faut-il changer de méthode pour fstrimer via un crontab pour de gros transferts ?

J'ai voulu copier du contenu de gros volumes (allant de 1Go jusqu'à 55Go) avec cp d'un point de montage à un autre.

Au début ça part en flèche 600Mb/s -> 300Mb/s -> 200Mb/s -> 100Mb/s pour aller jusqu'à 2Mb/s -> 500k/s puis freeze.

Sous Iotop, les copies sont presques inexistantes.

Au bou d'un moment, j'ai ce log qui apparait :

kernel: INFO: task jbd2/dm-6-8:1531 blocked for more than 120 seconds.
kernel:       Not tainted 6.12.90+deb13.1-amd64 #1 Debian 6.12.90-2
kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kernel: task:jbd2/dm-6-8     state:D stack:0     pid:1531  tgid:1531  ppid:2      flags:0x00004000
kernel: Call Trace:

Je me disais que ça pouvait être la température des disques, md1 j'ai 2x HDD et md2 2x SSD.
J'ai surveillé mais non.

Donc je penche pour le mécanisme de recopie d'un disque à l'autre éventuellement.

Si quelqu'un s'y connait en Raid :) Merci

# beauceoup d'erreur ?

Posté par NeoX le 15 juin 2026 à 16:08. Évalué à 4 (+1/-0).
- 6 disques en raid1 ? mais pourquoi …
  le raid1 c'est un miroir entre 2 disques, mais alors 6 ?
- le fstrim se fait sur un SSD ou un NVMe
- transfert qui fini par planter, un des disques qui serait foireux ?, plus assez de RAM pour 'bufferiser' le fichier a transferer ?
Répondre
- [^] # Re: beauceoup d'erreur ?
  
  Posté par electro575 le 15 juin 2026 à 16:19. Évalué à 1 (+0/-0).
  
  -6 disques en raid1 ? mais pourquoi …
  -le raid1 c'est un miroir entre 2 disques, mais alors 6 ?
  
  En fait,
  / : RAID 1 avec 2 SSD
  /srv/mountpoint1 : RAID 1 avec 2 HDD
  /srv/mountpoint2 : RAID 1 avec 2 SSD
  
  Le transfert se situe entre /srv/mountpoint1 et /srv/mountpoint2
  
  -le fstrim se fait sur un SSD ou un NVMe
  
  Ok, il y a t-il une solution plus efficace qu'une autre ?
  
  -transfert qui fini par planter, un des disques qui serait foireux ?
  
  C'est possible qu'un des disques finisse par faire ralentir l'opération mais smartctl remonte pas d'erreur à l'instant T.
  J'ai du mal à analyser toutes les tables SMART j'avoue
  
  -plus assez de RAM pour 'bufferiser' le fichier a transferer ?
  J'en ai 32 Go en DDR4, et ça bouge pas trop à ce niveau
  
  Répondre
  - [^] # Re: beauceoup d'erreur ?
    
    Posté par electro575 le 15 juin 2026 à 16:23. Évalué à 1 (+0/-0).
    
    J'ai un doute sur les 2 HDD si tu peux m'aider à ce sujet !
    
    sdb
    
    sdc
    
    Répondre
    - [^] # Re: beauceoup d'erreur ?
      
      Posté par MicP le 16 juin 2026 à 05:00. Évalué à 2 (+1/-0).
      Bonjour
      
      Extrait du lien sdb :
      
      Model Family: Seagate BarraCuda 3.5 (SMR) Device Model: ST4000DM004-2U9104 Serial Number: ZFN5VP75 … 1 Raw_Read_Error_Rate POSR-- 072 064 006 - 16646776 … 7 Seek_Error_Rate POSR-- 072 060 045 - 17621405 …
      
      AMHA, ces valeurs élevées pourraient indiquer que ce disque est en train de mourir => ce disque est à remplacer.
      
      … et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
      Répondre
      - [^] # Re: beauceoup d'erreur ?
        
        Posté par gUI (Mastodon) le 16 juin 2026 à 07:30. Évalué à 4 (+1/-0). Dernière modification le 16 juin 2026 à 07:30.
        
        Ça en plus du fait que c'est un disque SMR (cache interne très rapide, mais dès qu'il est saturé il gère très mal et les perfos s'effondrent), oui, envisage sérieusement de t'en séparer.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        Répondre
      - [^] # Re: beauceoup d'erreur ?
        
        Posté par xandercagexxx le 16 juin 2026 à 09:09. Évalué à 3 (+2/-0).
        
        Il me semble que les seagate affiche tjrs des valeurs très élevé, même sur des disques neuf donc pas sur que ce soit l'explication à ton soucis.
        
        Répondre
        
        [^] # Re: beauceoup d'erreur ?
        
        Posté par MicP le 16 juin 2026 à 10:32. Évalué à 1 (+0/-0).
        
        Oui, c'est pour ça que j'avais utilisé le conditionnel.
        Il faudrait voir ce qu'en pense Seagate.
        
        Il devrait être possible de tester le système RAID1 en mode dégradé <=> avec un seul des deux disques.
        
        … et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
        
        Répondre
      - [^] # Re: beauceoup d'erreur ?
        
        Posté par Craig77 le 16 juin 2026 à 16:40. Évalué à 1 (+0/-0).
        
        Ça peut aussi venir tout bêtement du câble SATA.
        
        Répondre
  - [^] # Re: beauceoup d'erreur ?
    
    Posté par NeoX le 16 juin 2026 à 10:40. Évalué à 5 (+2/-0). Dernière modification le 16 juin 2026 à 10:41.
```
cat /proc/mdstat
```
    pour en savoir plus sur ton raid, enfin au moins s'il voit les disques et s'ils sont UP
    
    pour un raid1, tu dois avoir par exemple (ca c'est le mien)
    ACTIVE => tout va bien
    [UU] => deux disques UP si mes souvenirs sont bons, si un disque est mort, tu aurais [U_] par exemple
```
Personalities : [raid0] [raid1] [raid4] [raid5] [raid6] [raid10] [linear] 
md2 : active raid1 sdb2[1] sda2[0]
      1046528 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md3 : active raid1 sdb3[1] sda3[0]
      20954112 blocks super 1.2 [2/2] [UU]
      bitmap: 1/1 pages [4KB], 65536KB chunk
```
    Répondre
# Commentaire supprimé

Posté par meoowu77 le 15 juin 2026 à 20:59. Évalué à -2 (+0/-3). Dernière modification le 16 juin 2026 à 07:25.

Ce commentaire a été supprimé par l’équipe de modération.

Répondre
# rsync

Posté par ChocolatineFlying le 16 juin 2026 à 11:26. Évalué à 2 (+1/-0).

pour ce genre de gros volume je préfère utiliser rsync, ca ne va peut etre pas resoudre ton pb

Répondre
# Réponses

Posté par WhiteCat le 21 juin 2026 à 17:29. Évalué à 2 (+0/-0). Dernière modification le 21 juin 2026 à 17:30.

Pour ce qui est du TRIM, j'ai l'option de montage "discard" mais faut-il changer de méthode pour fstrimer via un crontab pour de gros transferts ?

C'est pas la meilleure façon de faire. L'option "discard" dans le fstab n'est pas la plus recommandée :
"Running fstrim frequently, or even using mount -o discard, might
negatively affect the lifetime of poor-quality SSD devices. For
most desktop and server systems a sufficient trimming frequency is
once a week"
https://man7.org/linux/man-pages/man8/fstrim.8.html

Le mieux est d'utiliser le timer pour activer fstrim :
systemctl enable fstrim.timer

Je me disais que ça pouvait être la température des disques, md1 j'ai 2x HDD et md2 2x SSD.

Un SSD pourrait se brider en cas de surchauffe, mais ça ne bloquerait pas totalement les I/O.
Pour les disques durs, je n'ai jamais vu de problèmes de surchauffe.

le fstrim se fait sur un SSD ou un NVMe

Et tout volume en Thin-Provisonning aussi.

J'ai un doute sur les 2 HDD si tu peux m'aider à ce sujet !

Les 2 HDD sont nickels point de vue SMART.

AMHA, ces valeurs élevées pourraient indiquer que ce disque est en train de mourir => ce disque est à remplacer.
Raw_Read_Error_Rate / Seek_Error_Rate

Ces 2 paramètres ne veulent en général jamais rien dire.
Les plus importants pour un disque mourant sont les secteurs défectueux. Les paramètres à vérifier sont Reallocated_Sector_Ct, Current_Pending_Sector et Offline_Uncorrectable.

Sinon tu peux regarder les logs kernel ("dmesg -T |grep ata") pour voir si un disque pose problème. C'est généralement là qu'on voit si un disque est en train de mourir.

Ça en plus du fait que c'est un disque SMR (cache interne très rapide, mais dès qu'il est saturé il gère très mal et les perfos s'effondrent)

Pour de la lecture séquentielle, je ne pense pas que ces disques soient problématiques. Mais par contre ils sont connus pour devenir extrêmement lent en cas de grosses écritures…
Donc c'est peut-être la source du problème ici.
Mais on ne sait pas si les HDD sont utilisés pour la lecture ou pour l'écriture ?

Répondre

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.