Bonjour 
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 
Avez-vous une piste pour trouver le goulot d’étranglement ?
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 ?
Bonjour Pascal (je m’attendais a vous voir ici 
)
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 
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 …
Bon …
Le test SMART en GUI a planté
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
Au vu des ‘clik’ je crois que le disque va me lacher bientôt.
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/sec
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.
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 :
@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_OK
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)
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: Z4Z9RXGV
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.
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.
