Vitesse Raid6


#1

Bonjour :slight_smile:

Je suis récemment passé d’un raid5 a un raid6, depuis quelques temps j’ai remarqué que la vitesse de md7 est médiocre !
La config de la machine :
ASRock 960GC-GS FX
AMD FX™-6300 Six-Core Processor
2*4Gb ram ddr3

dev/md7:
        Version : 1.2
  Creation Time : Wed Mar  7 01:59:10 2018
     Raid Level : raid6
     Array Size : 5860151808 (5588.68 GiB 6000.80 GB)
  Used Dev Size : 1953383936 (1862.89 GiB 2000.27 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Aug  6 08:04:12 2019
          State : active 
 Active Devices : 5
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric-6
     Chunk Size : 512K

           Name : clonnezilla:1
           UUID : 
         Events : 124125

    Number   Major   Minor   RaidDevice State                              Réf. HDD
   0       8       33        0      active sync   /dev/sdc1                WDC WD20EZRZ
   1       8       65        1      active sync   /dev/sde1                ST2000DM006
   3       8       49        2      active sync   /dev/sdd1                ST2000DM006
   4       8       17        3      active sync   /dev/sdb1                ST2000DM008
   5       8       81        4      active sync   /dev/sdf1                 ST2000DM008

C’est le détail de ma grappe, il m’indique 5 Working Devices alors qu’il y a 6 disque, je suppose que c’est normale (?)

root@raid7:# hdparm -tT /dev/md7

/dev/md7:
 Timing cached reads:   7966 MB in  2.00 seconds = 3987.17 MB/sec
 Timing buffered disk reads:  22 MB in  3.34 seconds =   6.58 MB/sec



root@raid7:# dd if=/dev/zero of=/mnt/raid/testfile.out bs=1M count=10000
raid/
root@raid7:/home/raid7# dd if=/dev/zero of=/mnt/raid/testfile.out bs=1M count=10000
^C3193+0 enregistrements lus
3193+0 enregistrements écrits
3348103168 bytes (3,3 GB, 3,1 GiB) copied, 481,125 s, 7,0 MB/s

J’ai carrément stoppé le test après quelques minutes…

root@raid7:# dd if=/mnt/raid/testfile.out of=/dev/null bs=1M
3193+0 enregistrements lus
3193+0 enregistrements écrits
3348103168 bytes (3,3 GB, 3,1 GiB) copied, 530,641 s, 6,3 MB/s

7 MB/s c’est vraiment faible :frowning:
Avez-vous une piste pour trouver le goulot d’étranglement ?


#2

Conversion d’un ensemble RAID 5 existant avec --grow ou re-creation d’un ensemble RAID 6 ?

Cet ensemble RAID ne comprend que 5 disques, pas 6, et il n’en manque aucun. La capacité utile totale de 6 To est cohérente avec le nombre de disques (5 disques - 2 pour la redondance) * 2 To = 6 To.

En effet. Le RAID 6 demande plus de puissance de calcul que le RAID 5 pour la double parité, mais le processeur devrait être suffisant.
As-tu mesuré le débit des membres individuels avec hdparm ?


#3

Bonjour Pascal (je m’attendais a vous voir ici :stuck_out_tongue: )
Passage a raid6 avec un grow

   root@raid7:# hdparm -tT /dev/sdc
sdc   sdc1  
root@raid7:/home/raid7# hdparm -tT /dev/sdc1

/dev/sdc1:
 Timing cached reads:   8194 MB in  2.00 seconds = 4101.88 MB/sec
 Timing buffered disk reads: 288 MB in  3.01 seconds =  95.73 MB/sec

root@raid7:# hdparm -tT /dev/sde1

/dev/sde1:
 Timing cached reads:   2320 MB in  2.00 seconds = 1160.28 MB/sec
 Timing buffered disk reads:   4 MB in  3.26 seconds =   1.23 MB/sec

root@raid7:~# hdparm -tT /dev/sdd1

/dev/sdd1:
 Timing cached reads:   8116 MB in  2.00 seconds = 4062.21 MB/sec
 Timing buffered disk reads: 388 MB in  3.01 seconds = 128.93 MB/sec
root@raid7:~# hdparm -tT /dev/sdb1

/dev/sdb1:
 Timing cached reads:   8228 MB in  2.00 seconds = 4118.33 MB/sec
 Timing buffered disk reads: 388 MB in  3.01 seconds = 129.11 MB/sec
root@raid7:~# hdparm -tT /dev/sdf1

/dev/sdf1:
 Timing cached reads:   8116 MB in  2.00 seconds = 4062.45 MB/sec
 Timing buffered disk reads: 288 MB in  3.00 seconds =  95.97 MB/sec
root@raid7:~# hdparm -tT /dev/sde1

/dev/sde1:
 Timing cached reads:   1048 MB in  2.00 seconds = 523.99 MB/sec
 Timing buffered disk reads:   6 MB in  3.94 seconds =   1.52 MB/sec

C’est donc sde qui me pose problème !
sde c’est ST2000DM006 soit 7200 RPM 64 Mo et sdb est le même modèle mais j’ai pas les même résultat :roll_eyes:
Es que je dois faire aussi une vérif de d’écriture, si oui comment ?

J’y pense j’entends de temps en temps un ‘clik’ dû au déplacement de la tête de lecture es que ça peut avoir un rapport ? j’ai rien de signalé au niveau SMART. Je viens de lancer un test SMART en graphique …


#4

Bon …
Le test SMART en GUI a planté :frowning:
j’en ai donc fait :

   root@raid7:~# smartctl -t short /dev/sde
    smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.15.0-55-generic] (local build)
    Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
    === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
    Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
    Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
    Testing has begun.
    Please wait 1 minutes for test to complete.
    Test will complete after Tue Aug  6 14:30:19 2019

Use smartctl -X to abort test.
root@raid7:~# smartctl -t short /dev/sde1
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.15.0-55-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

Smartctl open device: /dev/sde1 failed: INQUIRY failed
root@raid7:~# cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md7 : active raid6 sdf1[5] sdb1[4] sdc1[0] sdd1[3]
      5860151808 blocks super 1.2 level 6, 512k chunk, algorithm 18 [5/4] [U_UUU]
      bitmap: 10/15 pages [40KB], 65536KB chunk

J’ai donc perdu sde, j’ai redémarré la machine et là

 root@raid7:~# hdparm -tT /dev/sde
        /dev/sde:
         Timing cached reads:   8542 MB in  2.00 seconds = 4275.48 MB/sec
         Timing buffered disk reads: 588 MB in  3.00 seconds = 195.96 MB/sec
        root@raid7:~# hdparm -tT /dev/sde1

    /dev/sde1:
     Timing cached reads:   8492 MB in  2.00 seconds = 4250.09 MB/sec
     Timing buffered disk reads: 592 MB in  3.01 seconds = 196.83 MB/sec

C’est redevenue correcte ! Je penche pour un problème matériel, un câble SATA trop vieux/usagé ?

Le retour de smart

root@raid7:~# smartctl --all /dev/sde1
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.15.0-55-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:    Tue Aug  6 14:58:05 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:      ( 249)	Self-test routine in progress...
					90% of test remaining.
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   119   099   006    Pre-fail  Always       -       204296576
  3 Spin_Up_Time            0x0003   098   097   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   094   094   020    Old_age   Always       -       6314
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   085   060   030    Pre-fail  Always       -       4643723314
  9 Power_On_Hours          0x0032   086   086   000    Old_age   Always       -       12402
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       47
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   065   057   045    Old_age   Always       -       35 (Min/Max 34/35)
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       -       6288
193 Load_Cycle_Count        0x0032   096   096   000    Old_age   Always       -       8912
194 Temperature_Celsius     0x0022   035   043   000    Old_age   Always       -       35 (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      -       12055 (114 115 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       56310145175
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       108823246129

SMART Error Log Version: 1
No Errors Logged

donc le test court est bon, j’attends le résultat du test long (si je ne le perd pas entre temps…)
edit: je n’arrive pas a finir les tests étendu :frowning:
Au vu des ‘clik’ je crois que le disque va me lacher bientôt.


#5

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) ?


#6

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/sec

#7

En 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.


#8

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.


#9

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/


#10

@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 /


#11

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_OK

#12

Bonsoir,

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)


#13

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).


#14

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.


#15

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.


#16

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.


#17

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.


#18

Salut :slight_smile:
Alors j’ai voulu savoir où était sde sur mon ‘rack’ de hdd en débranchant l’alim et je me suis trompé :sweat:
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 :sweat_smile:

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.Capture%20du%202019-08-10%2015-18-45

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 :slight_smile:
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:    Z4Z9RXGV

#19

Salut,

Je suis levé depuis très tôt et je ne veux pas induire d’erreur.
Je pense que @PascalHambourg va te répondre.


#20

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.