Raid 1 DegradedArray event on /dev/md2

Bonjour,

Ce matin j’ai reçu par email plusieurs avertissements

DegradedArray event on /dev/md/2
DegradedArray event on /dev/md/3
DegradedArray event on /dev/md/4
DegradedArray event on /dev/md/5
DegradedArray event on /dev/md/6

Avec [mono]cat /proc/mdstat[/mono] j’obtiens :

[code]Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
[multipath] [faulty]
md4 : active raid1 sda4[0] sdb41
30702464 blocks super 1.2 [2/1] [U_]

md2 : active raid1 sdb22 sda2[0]
174078912 blocks [2/1] [U_]

md3 : active raid1 sdb32 sda3[0]
174078912 blocks [2/1] [U_]

md5 : active raid1 sdb52 sda5[0]
857829312 blocks [2/1] [U_]

md6 : active raid1 sdb62 sda6[0]
716797888 blocks [2/1] [U_]

unused devices: [/code]

J’ai essayé différentes manips :

root@ns1:/home/XX# mdadm --re-add /dev/md4 /dev/sdb4 mdadm: Cannot open /dev/sdb4: Device or resource busy root@ns1:/home/XX# mdadm --remove /dev/md4 /dev/sdb4 mdadm: hot removed /dev/sdb4 from /dev/md4 root@ns1:/home/XX# mdadm --add /dev/md4 /dev/sdb4 Erreur de segmentation

Et donc je ne peux pas reconstruire…

[mono]mdadm -D /dev/md4[/mono]

[code]/dev/md4:
Version : 1.2
Creation Time : Fri Aug 29 13:50:50 2014
Raid Level : raid1
Array Size : 30702464 (29.28 GiB 31.44 GB)
Used Dev Size : 30702464 (29.28 GiB 31.44 GB)
Raid Devices : 2
Total Devices : 1
Persistence : Superblock is persistent

Update Time : Thu Sep  3 13:05:01 2015
      State : clean, degraded

Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0

       Name : ns1.site.tld:4  (local to host ns1.site.tld)
       UUID : bb369514:dd27de98:e4fe783f:2a8d8313
     Events : 37248

Number   Major   Minor   RaidDevice State
   0       8        4        0      active sync   /dev/sda4
   1       0        0        1      removed

[/code]

Je suis un peu bloqué et aussi un peu perdu n’ayant jamais fait ce genre de manipulations. Je cherche mais pour le moment je ne trouve pas d’informations.
Je poste pour savoir si éventuellement vous aurez une solution. Si j’en trouve une de mon côté je posterais ici.

Merci par avance

Plusieurs partitions RAID du disque /dev/sdb ont été marquées défaillantes (F). Il y a a priori une raison. Il ne me semble pas très sain d’essayer de les réintégrer sans avoir fait un diagnostic du disque (logs du noyau et de mdadm, test du disque avec smartctl et badblocks…).

En attendant le RAID marche sur une patte et n’a plus de redondance ; si la disponibilité est importante, il vaudrait mieux ajouter un nouveau disque avant de vérifier le disque suspect.

Merci pour ta réponse,

Le problème étant que c’est un serveur de production (web), mais aussi que c’est un serveur que je loue… Donc je me demande si c’est une bonne idée de demander à mon prestataire de faire le changement ?! (les données il n’en a rien à faire)

La disponibilité est assez importante (pas mal d’utilisateurs sur les sites), du coup je suis un peu paumé sur la procédure à faire :confused: vu ce que j’ai annoncé, pense-tu que je doive faire l’analyse sans changement de disque, ou dois-je contacter l’hébergeur du serveur pour faire un changement de disque?
Lequel est le plus risqué ? (et surtout quel serait le risque le plus grave ? que le bon disque soit endommagé dans les manips ? ou lui aussi changé par le prestataire en plus du défaillant ?)

Désolé de toutes ces questions, je suis un peu paumé par ce qu’il se passe :005

Aucun risque d’endommager le bon disque si tu ne te plantes pas dans les commandes. Par contre actuellement le serveur est maintenant sans redondance et à la merci d’une défaillance du bon disque.

Pour les autres questions, je ne peux pas répondre à ta place. C’est toi l’administrateur.

Salut,

Quelles seraient les commandes à taper pour vérifier le bon fonctionnement du disque, et éventuellement le reconstruire ?

J’ai vu ce sujet : raid-1-degradedarray-event-on-dev-md-0-t44798.html

Donc j’ai lancé une partie des commandes pour vérifier (voir première message) et ensuite les commandes pour reconstruire

root@ns1:/home/XX# mdadm -E  /dev/sdb4
mdadm: No md superblock detected on /dev/sdb4.
root@ns1:/home/XX# mdadm /dev/md4 -r /dev/sdb4
mdadm: hot remove failed for /dev/sdb4: No such device or address
root@ns1:/home/XX# mdadm  /dev/md4 -f /dev/sdb4
mdadm: set device faulty failed for /dev/sdb4:  No such device
root@ns1:/home/XX# mdadm --assemble --force /dev/md4 /dev/sdb4
mdadm: no recogniseable superblock on /dev/sdb4
mdadm: /dev/sdb4 has no superblock - assembly aborted

[code]root@ns1:/home/XX# smartctl -a /dev/sdb
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.10.23-xxxx-std-ipv6-64] (local build)
Copyright © 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

Short INQUIRY response, skip product id
A mandatory SMART command failed: exiting. To continue, add one or more ‘-T permissive’ options.
root@ns1:/home/XX# y SMART command failed: exiting. To continue, add one or more ‘-T permissive’ options.
bash: y : commande introuvable
root@ns1:/home/tantang# smartctl -a /dev/sda
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.10.23-xxxx-std-ipv6-64] (local build)
Copyright © 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model: ST2000DM001-1CH164
Serial Number: W2F0KQVC
LU WWN Device Id: 5 000c50 05c7048ea
Firmware Version: CC43
User Capacity: 2 000 398 934 016 bytes [2,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Fri Sep 4 11:46:04 2015 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: ( 600) 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: ( 255) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x3085) 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 112 099 006 Pre-fail Always - 44128360
3 Spin_Up_Time 0x0003 091 091 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 25
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 069 060 030 Pre-fail Always - 167825230863
9 Power_On_Hours 0x0032 076 076 000 Old_age Always - 21071
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 25
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
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 052 045 Old_age Always - 35 (Min/Max 18/48)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 25
193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 43
194 Temperature_Celsius 0x0022 035 048 000 Old_age Always - 35 (0 18 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 200 000 Old_age Always - 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 29661044167239
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 46052504755
242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 111989991921

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 Short offline Completed without error 00% 6298 -

2 Short offline Completed without error 00% 6290 -

3 Short offline Completed without error 00% 6290 -

4 Short offline Completed without error 00% 1020 -

5 Short offline Completed without error 00% 1008 -

6 Short offline Completed without error 00% 1008 -

7 Short offline Completed without error 00% 1006 -

8 Short offline Completed without error 00% 33 -

9 Short offline Completed without error 00% 21 -

#10 Short offline Completed without error 00% 21 -
#11 Short offline Completed without error 00% 0 -

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):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
[/code]

Malheureusement je reste bloqué et perdu par ce qu’il faut faire, et surtout je n’ai pas envie de faire de conneries :119

Ton SDB est HS: verifie quand meme dans /var/log/kern.log tu devrais avoir des indications…

[code]/home/XX# smartctl -a /dev/sdb
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.10.23-xxxx-std-ipv6-64] (local build)
Copyright © 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

Short INQUIRY response, skip product id
A mandatory SMART command failed: exiting. To continue, add one or more ‘-T permissive’ options.
root@ns1:/home/XX# y SMART command failed: exiting. To continue, add one or more ‘-T permissive’ options.
bash: y : commande introuvable[/code]

Ou alors ton câble sata mais c’est plus rare…

Tu vas etre obligé de passer par une coupure de service… contraitement au hot swap tu ne pourras pas faire de remplacement à chaud.

Une fois le disque remplacé:
#fdisk -l

Bien vérifier que Sdb apparait et qu’il n’est pas “formaté”

si tu as l’erreur : sfdisk: ERROR: sector 0 does not have an msdos signature
ajoute la commande --force se qui donnera :
On recopie le partitionnement du sda

on verifie dans md que se trouve les partitions à ajouter:

Puis:

etc selon tes partitions…

n’oublie pas si tu as de la swap:

cat /proc/swaps Filename Type Size Used Priority /dev/sdb3 partition 522104 43984 -1 Il faut maintenant réajouter le swap du disque que vous venez de formater et reajouter au RAID. mkswap /dev/sda3 swapon -a

J’ai pris sda3 pour l’exemple…

Voila une piste pour ton changement de disque
Bon courage.

Le disque n’est pas forcément HS, mais il y a bien un problème de communication qui peut venir du disque, du câble, du contrôleur hôte… voire d’un bug d’un pilote du noyau, ça s’est déjà vu. Comme tu dis l’examen des logs du noyau pourrait en apprendre plus après avoir quand même tenté la suggestion de smartctl (sans grande conviction) :

[mono]sfdisk[/mono] est utilisable pour dupliquer la table de partition à condition que celle-ci soit au format MSDOS, car la version de Jessie (je n’ose imaginer un serveur de prod en testing) ne comprend pas le format GPT. Les disques ont une capacité de 2 To donc le format GPT n’est pas obligatoire pour les exploiter en entier, mais d’après les numéros des partitions utilisées comme membres des ensembles RAID, je soupçonne que la table soit au format GPT (avec le format MSDOS, il y aurait forcément une partition étendue en première position suivie par 3 partitions principales, ce qui est assez inhabituel). Dans ce cas il faudra utiliser [mono]gdisk[/mono] ou [mono]sgdisk[/mono] inclus dans le paquet gdisk (attention : leurs options et commandes sont différentes de celles des fdisk et sfdisk originels).

Sur un système en RAID, il serait logique que le swap soit en RAID donc on ne devrait pas avoir besoin de s’en occuper, juste reconstruire son ensemble RAID comme les autres.

Pour [mono]/var/log/kern.log[/mono] j’avais regardé et en effet j’ai des erreurs (enfin je pense), désolé j’avais complétement oublié de les mettre dans mon précédent message :

Sep 4 12:00:43 ns1 kernel: Read(10): 28 00 29 81 00 00 00 00 08 00 Sep 4 12:00:43 ns1 kernel: end_request: I/O error, dev sdb, sector 696320000 Sep 4 12:00:43 ns1 kernel: Buffer I/O error on device sdb4, logical block 0 Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 12:00:43 ns1 kernel: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] CDB: Sep 4 12:00:43 ns1 kernel: Read(10): 28 00 29 81 00 08 00 00 08 00 Sep 4 12:00:43 ns1 kernel: end_request: I/O error, dev sdb, sector 696320008 Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 12:00:43 ns1 kernel: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] CDB: Sep 4 12:00:43 ns1 kernel: Write(10): 2a 00 29 81 00 08 00 00 01 00 Sep 4 12:00:43 ns1 kernel: end_request: I/O error, dev sdb, sector 696320008 Sep 4 12:00:43 ns1 kernel: mdadm[3270]: segfault at 8 ip 000000000042f4fa sp 00007fff81b6f260 error 4 in mdadm[400000+67000] Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 12:00:43 ns1 kernel: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] CDB: Sep 4 12:00:43 ns1 kernel: Read(10): 28 00 2d 2a 77 80 00 00 08 00 Sep 4 12:00:43 ns1 kernel: Buffer I/O error on device sdb4, logical block 7679728 Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 12:00:43 ns1 kernel: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] CDB: Sep 4 12:00:43 ns1 kernel: Read(10): 28 00 2d 2a 77 80 00 00 08 00 Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 12:00:43 ns1 kernel: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] CDB: Sep 4 12:00:43 ns1 kernel: Read(10): 28 00 2d 2a 77 f0 00 00 08 00 Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 12:00:43 ns1 kernel: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] CDB: Sep 4 12:00:43 ns1 kernel: Read(10): 28 00 2d 2a 77 f0 00 00 08 00 Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 12:00:43 ns1 kernel: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] CDB: Sep 4 12:00:43 ns1 kernel: Read(10): 28 00 29 81 00 00 00 00 08 00 Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 12:00:43 ns1 kernel: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] CDB: Sep 4 12:00:43 ns1 kernel: Read(10): 28 00 29 81 00 00 00 00 08 00 Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 12:00:43 ns1 kernel: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] CDB: Sep 4 12:00:43 ns1 kernel: Read(10): 28 00 29 81 00 08 00 00 08 00 Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 12:00:43 ns1 kernel: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] CDB: Sep 4 12:00:43 ns1 kernel: Read(10): 28 00 2d 2a 77 f8 00 00 08 00 Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Unhandled error code Sep 4 12:00:43 ns1 kernel: sd 1:0:0:0: [sdb] Sep 4 16:00:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:00:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:00:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:00:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:00:25 ns1 kernel: IN=eth0 OUT= MAC=00:25:90:7b:7c:42:1c:e6:c7:52:af:80:08:00 SRC=114.142.244.41 DST=37.59.8.129 LEN=138 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO =UDP SPT=53 DPT=20727 LEN=118 Sep 4 16:00:32 ns1 kernel: IN=eth0 OUT= MAC=00:25:90:7b:7c:42:e8:ba:70:42:e4:80:08:00 SRC=222.186.61.2 DST=37.59.8.129 LEN=40 TOS=0x00 PREC=0x00 TTL=104 ID=256 PROTO=TC P SPT=6000 DPT=1433 WINDOW=16384 RES=0x00 SYN URGP=0 Sep 4 16:01:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:01:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:01:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:01:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:02:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:02:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:03:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Sep 4 16:03:01 ns1 kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO

Et pour [mono]smartctl -a -T permissive /dev/sdb[/mono]

[code]smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.10.23-xxxx-std-ipv6-64] (local build)
Copyright © 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

Short INQUIRY response, skip product id
SMART Health Status: OK
Read defect list: asked for grown list but didn’t get it

Error Counter logging not supported
Device does not support Self Test logging[/code]

Sinon la swap est en effet en RAID1 aussi (mais j’ai dû le créer, au départ elle ne l’était pas)

Effectivement je n’avais pas vu l’info sur la capacité du disque 2To donc le format GPT !

:unamused:

Je répète que le format GPT n’est pas obligatoire pour un disque jusqu’à 2 To, le format MSDOS étant capable de prendre en compte cette taille. C’est un autre indice, les numéros des partitions RAID, qui me fait suspecter le format GPT.

Les erreurs dans les logs du noyau ne me semblent pas être celles qu’on rencontre lorsqu’on tente de lire ou écrire dans des secteurs défectueux. Je suis incapable de les interpréter et de dire si ça vient du disque ou du contrôleur SATA hôte ou de la liaison entre les deux. Si jusqu’ici le serveur tournait sans erreur avec le noyau actuel, je pense qu’on peut néanmoins exclure un bug logiciel.

Le serveur a effectivement tourné pendant 2 ans sans avoir rencontré problème!
Et les logs que j’ai affiché se sont répétés continuellement. (il n’y en a pas d’autres)
Donc si ce n’est pas logiciel, je suppose que cela ne peut être que matériel ? (a moins que je loupe quelque chose qui devrait être évident)

Mais pas avec le même noyau, j’espère (ou alors tu patches les failles à chaud avec ksplice ou équivalent).

Si le problème s’est produit peu après une mise à jour du noyau, on ne peut exclure une régression dans la dernière version. Mais comme il y a des mises à jour du noyau assez souvent et qu’un bug ne se déclenche pas forcément tout de suite, ce n’est pas forcément évident de faire le lien.

Dans le cas contraire, c’est probablement matériel mais pas forcément le disque.

A titre d’exemple j’ai eu un dysfonctionnement de disque récemment sur une machine que je n’avais pas allumée depuis longtemps. Au début j’ai vraiment cru que le disque était défectueux. En fait le fautif était l’adaptateur d’alimentation Molex-SATA qui devait faire mauvais contact et n’envoyait que 4,5 V vers le disque au lieu des 5 V réglementaires.

Pardon j’ai mal répondu à la question.
Le serveur n’a pas été mis à jour depuis la sortie de jessie, donc environ 4 mois. (le serveur est en version Wheezy 7.8 ) Mon serveur de test était HS jusqu’à récemment, j’ai préféré stoppé les maj jusqu’à ce qu’il soit de nouveau opérationnel.

Merci pour ton exemple, je vais contacter le service technique voir s’ils peuvent regarder le problème. Au moins je serai fixé de savoir si c’est matériel ou non.