Possible mais douteux que le disque devienne inaccessible pile lors de l’auto-test à cause du câble. Vérifier l’alimentation aussi.
Je ne vois aucune anomalie dans le rapport SMART, excepté qu’on n’y voit pas le résultat de l’auto-test. Est-ce qu’il y avait des messages d’erreur concernant sde dans les logs du noyau d’avant l’auto-test ?
Est-ce que le débit de l’ensemble RAID est devenu correct (si le disque a été réintégré dans l’ensembre RAID) ?
Oui effectivement pour les câbles c’est douteux, en ce qui concerne l’alim je ne vois pas trop comment la tester, c’est une VS450 et il n’y a rien d’autre que les 6 disque et la cm+proc.
Oui après avoir réintégrer sde dans la grappe j’ai un bon débit :
Comment je peut le vérifier ?
/dev/md7:
Timing cached reads: 8326 MB in 2.00 seconds = 4166.90 MB/sec
Timing buffered disk reads: 894 MB in 3.01 seconds = 297.31 MB/secEn examinant les logs du noyau /var/log/kern* à la date du dysfonctionnement et de l’auto-test. Attention, les logs les plus anciens sont compressés.
Alors déjà, une baisse de perf de l’un à l’autre, c’est une différence confirmée entre raid 5 et 6.
Ben si un disque est tombé (bon, j’imagine que tu aurais eu des messages de logs) mécaniquement, la performance me semble devoir baisser, car tu as moins de ressources pour répartir/parallèliser les I/O.
Bon, c’est juste pour faire avancer les choses, je n’ai pas mis le nez dans du raid depuis des décennies.
Dans ce cas zless et zgrep sont nos amis
Pareil pour les tests d’écriture regarde aussi avec des paquets de 512ko et tester avec IOzone :
http://www.iozone.org/
@PascalHambourg
Je ne me souviens plus des dates, je vais attendre que le bug ce reproduise
@mattotop
En fait je me suis trompé : il y’a 6 disques au total 5*2to + le ssd pour le /
Voila ça c’est encore produit.
Voici un extrait de kern.log
Aug 9 21:20:45 raid7 kernel: [38567.363605] ata5.01: configured for UDMA/100
Aug 9 21:20:45 raid7 kernel: [38567.363625] sd 4:0:0:0: [sde] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Aug 9 21:20:45 raid7 kernel: [38567.363631] sd 4:0:0:0: [sde] tag#0 Sense Key : Not Ready [current]
Aug 9 21:20:45 raid7 kernel: [38567.363635] sd 4:0:0:0: [sde] tag#0 Add. Sense: Logical unit not ready, hard reset required
Aug 9 21:20:45 raid7 kernel: [38567.363641] sd 4:0:0:0: [sde] tag#0 CDB: Read(10) 28 00 55 26 9e 48 00 00 08 00
Aug 9 21:20:45 raid7 kernel: [38567.363644] print_req_error: I/O error, dev sde, sector 1428594248
Aug 9 21:20:45 raid7 kernel: [38567.363672] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363679] sd 4:0:0:0: killing request
Aug 9 21:20:45 raid7 kernel: [38567.363686] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363691] sd 4:0:0:0: [sde] killing request
Aug 9 21:20:45 raid7 kernel: [38567.363695] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363706] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363715] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363724] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363733] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363741] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363750] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363758] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363767] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363775] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363784] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363792] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363800] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363808] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363816] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363835] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363859] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363881] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363887] print_req_error: I/O error, dev sde, sector 2064
Aug 9 21:20:45 raid7 kernel: [38567.363891] md: super_written gets error=10
Aug 9 21:20:45 raid7 kernel: [38567.363897] md/raid:md7: Disk failure on sde1, disabling device.
Aug 9 21:20:45 raid7 kernel: [38567.363897] md/raid:md7: Operation continuing on 4 devices.
Aug 9 21:20:45 raid7 kernel: [38567.363953] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363970] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.363977] print_req_error: I/O error, dev sde, sector 0
Aug 9 21:20:45 raid7 kernel: [38567.363987] ata5: EH complete
Aug 9 21:20:45 raid7 kernel: [38567.364034] sd 4:0:0:0: [sde] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Aug 9 21:20:45 raid7 kernel: [38567.364039] sd 4:0:0:0: [sde] CDB: Read(10) 28 00 55 26 9e 50 00 00 08 00
Aug 9 21:20:45 raid7 kernel: [38567.364043] print_req_error: I/O error, dev sde, sector 1428594256
Aug 9 21:20:45 raid7 kernel: [38567.364149] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.364161] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.364171] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.364183] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.364191] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.364200] sd 4:0:0:0: rejecting I/O to offline device
Aug 9 21:20:45 raid7 kernel: [38567.527578] ata5.00: detaching (SCSI 4:0:0:0)
Aug 9 21:20:45 raid7 kernel: [38567.528367] sd 4:0:0:0: [sde] Stopping disk
Aug 9 21:20:45 raid7 kernel: [38567.528397] sd 4:0:0:0: [sde] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OKBonsoir,
Il semble que tu aies tout intérêt à remplacer ce disque sde rapidement.
Ne serait-ce que pour rétablir l’intégrité de ton miroir,
et puis éventuellement pour tester ce disque défaillant séparément.
Les câbles SATA de données peuvent vite vieillir ;
Ils sont donnés pour un nombre de branchements limité.
Perso, je préfère maintenant ceux avec des clips métalliques de maintien ;
et aussi de bonne épaisseur (AWG)
Apparemment il s’agit d’un disque qui ne répond plus, comme s’il était déconnecté. Cela peut provenir d’un défaut de la connectique (câble SATA, connecteurs du disque, de la carte mère ou d’alimentation) ou d’un problème électronique (contrôleur du disque, port du contrôleur SATA hôte).
Des tests croisés en permutant chacun de ces éléments un par un pourraient aider à déterminer l’élément défectueux (la panne devrait suivre cet élément).
J’approuve mais c’est cependant au risque de se trouver avec un autre disque hors du miroir…
Et dans ce cas là, bonjour pour la reconstruction.
C’est un RAID 6, qui supporte la perte de deux disques. D’autre part si on fait une permutation seulement lorsque tous les disques sont marqués actifs dans le RAID, dans l’hypothèse probable où le défaut ne serait causé que par un seul élément (sinon c’est vraiment pas de bol), un seul disque devrait être impacté. Par contre les tests croisés ne seront pas forcément probants si le dysfonctionnement est causé par une incompatibilité spécifique entre deux éléments.
Oui, je sais.
Et la reconstruction de deux disques perdus prend - il parait - un temps phénoménal.
Ce qui peut fatiguer les autres.
C’est jouable, probablement…
Avoir de bons câbles serait un atout.
Si le code est bien écrit, la reconstruction synchrone de deux disques ne devrait pas prendre plus de temps que la reconstruction d’un seul disque, les mêmes données lues sur les disques restants servant à reconstruire les deux disques simultanément. Néanmoins je conçois que la reconstruction de deux disques “en décalé” (quand on lance la reconstruction d’un second disque pendant que la reconstruction d’un autre disque est déjà en cours) puisse être une opération très laborieuse. En fait dans ce cas il me semblerait préférable d’attendre la fin de la reconstruction du premier disque avant de démarrer celle du second.
Mais je n’ai jamais utilisé le RAID 6, donc je n’ai pas d’expérience pratique à l’appui de mes allégations.
Salut 
Alors j’ai voulu savoir où était sde sur mon ‘rack’ de hdd en débranchant l’alim et je me suis trompé 
Résultat mon raid6 passe a 2 disque hors de la grappe… j’ai remonté les 2 hdd un a un (j’ai pas voulu prendre le risque de faire les 2 en même temps ne sachant pas comment pourrait se comporter mdadm, le tout en moins de 2h ! merci au bitmap (si j’ai bien compris c’est son rôle dans ce genre de situation) le tout sous un orage assez intense et sans onduleur online 
Donc on reviens a l’hypothèse matériel, j’avais déjà eu un problème similaire sur la même machine qui avait été résolut via un changement de câble SATA, je vous l’avoue j’ai tendance a torturer les câbles SATA avec des serflex pour le management des câbles.
Je vais donc tester sde sur une autre machine, après l’avoir identifié dans ce stack… Le disque est encore sous garantie jusqu’en février 2020
J’ai un doute sur le fonctionnement de l’attribution des périphériques: la lettre sdX est attribué en fonction des port SATA sur la CM si rien n’est inscrit dans le fstab, actuellement je n’ai que
UUID=945481f0-971d-4cfb-b2c0-0372f67b8b56 / ext4 errors=remount-ro 0 1
UUID=5139b22c-d8f2-4765-9843-f8d54485fa27 none swap sw 0 0
/dev/disk/by-uuid/cbc48f3e-4fe1-4d21-96ab-212cd0016ae5 /mnt/raid/ auto nosuid,nodev,nofail,x-gvfs-show 0 0
les 2 premiers : SSD
et le dernier : grappe (md7 actuellement)
Donc si je débranche/rebranche tout les disque en inversant des câbles je risque d’avoir a faire une reconstruction ou pas ?
Je viens de me rendre compte que le disque identifié en tant que sde l’est maintenant en tant que sda, je ne comprend pas pourquoi ce changement vu que je n’ai pas interchangé de câble SATA…
raid7@raid7:~$ sudo smartctl --all /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-55-generic] (local build)
=== START OF INFORMATION SECTION ===
Device Model: ST2000DM006-2DM164
Serial Number: Z4Z9RXGVSalut,
Je suis levé depuis très tôt et je ne veux pas induire d’erreur.
Je pense que @PascalHambourg va te répondre.
Le nommage des disques /dev/sd* se fait dans l’ordre de leur découverte. Cela peut être plus ou moins lié à leur position sur les ports SATA hôtes, mais il ne faut pas trop compter dessus. Bref, ne pas compter sur les noms /dev/sd* pour identifier les disques de façon persistante. Il faut s’attendre à ce que les noms changent d’un démarrage à l’autre même sans aucun changement matériel.
Le contenu de /etc/fstab n’a aucune influence sur le nommage des disques. C’est plutôt l’inverse. Du coup on fait en sorte sorte de ne pas dépendre des noms de périphériques non persistants, par exemple en utilisant les UUID ou labels.
Normalement non, sauf si un disque est mal rebranché et non détecté, ou si les membres de l’ensemble RAID sont spécifiés par leurs noms /dev/sd* dans /etc/mdadm/mdadm.conf, ce qui serait une très mauvaise idée.
Bonjour
J’ai eu à faire à une machine qui avait des connecteurs molex LP4 mâle et femelle
dont les broches étaient mal serties, ce qui occasionnait des faux contacts
entraînant une chute de tension lors d’appels de courant un peu trop fort.
Ces chutes de tension provoquaient parfois un redémarrage du disque dur.
Je m’en suis aperçu en tirant avec mes doigts sur chacun des conducteurs séparément,
et ceux qui étaient mal sertis se sont rapidement dessertis,
sans avoir eu à tirer bien fort dessus.
Pour résoudre le problème, j’ai re-serti chacun des conducteurs
avant de les souder à l’étain.
Salut,
Je profite du mois d’août loin de mes machines ce qui explique l’absence de réponses.
Effectivement j’ai des adaptateur molex vers sata je vais donc les tester et aussi faire un test du disque défectueux sur un autre machine.
Je reviendrais poster mes résultats ici.
Bonne vacances pour ceux qui en ont 
Bon j’ai fait un test sans rien toucher a la config et il me retourne :
raid7@raid7:~$ sudo smartctl --all /dev/sdh
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-58-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: ST2000DM006-2DM164
Serial Number: Z4Z9RXGV
LU WWN Device Id: 5 000c50 0a5c4e4c1
Firmware Version: CC26
User Capacity: 2 000 398 934 016 bytes [2,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Wed Sep 4 14:32:24 2019 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 80) seconds.
Offline data collection
capabilities: (0x73) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 209) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x1085) SCT Status supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 115 099 006 Pre-fail Always - 92294616
3 Spin_Up_Time 0x0003 098 097 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 093 093 020 Old_age Always - 7416
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 085 060 030 Pre-fail Always - 4663532806
9 Power_On_Hours 0x0032 086 086 000 Old_age Always - 13092
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 49
183 Runtime_Bad_Block 0x0032 099 099 000 Old_age Always - 1
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 071 057 045 Old_age Always - 29 (Min/Max 26/33)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 097 097 000 Old_age Always - 7390
193 Load_Cycle_Count 0x0032 095 095 000 Old_age Always - 10031
194 Temperature_Celsius 0x0022 029 043 000 Old_age Always - 29 (0 19 0 0 0)
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 153 000 Old_age Always - 11277
240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 12715 (144 222 0)
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 60608790526
242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 113871656114
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 12986 -
# 2 Short offline Completed without error 00% 12977 -
# 3 Extended offline Interrupted (host reset) 00% 12470 -
# 4 Conveyance offline Interrupted (host reset) 00% 12403 -
# 5 Extended offline Interrupted (host reset) 00% 12402 -
# 6 Short offline Interrupted (host reset) 00% 12402 -
# 7 Short offline Completed without error 00% 12402 -
# 8 Short offline Completed without error 00% 12402 -
# 9 Short offline Completed without error 00% 12402 -
#10 Short offline Interrupted (host reset) 00% 12402 -
#11 Extended offline Interrupted (host reset) 00% 12402 -
#12 Extended offline Interrupted (host reset) 00% 8475 -
#13 Short offline Completed without error 00% 5 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
tout semble ok …