Erreur sur Raid5 : Primary GPT table is corrupt

Eric_fr75 · Juin 22, 2017, 10:27am

Bonjour,

Utilisateur d’OpenMediaVault, basé sur Debian, je rencontre actuellement un problème avec mon Raid5 après une coupure de courant.

Voici ma configuration :

Intel Core i7 920 LGA 1366, 8M Cache, 2.66 GHz
Corsair 12Go DDR3 1333
ASUS Sabertooth x58 + Carte PCIex USB3

OMV
Samsung SSD 850 PRO 128 Go

Raid 5
SEAGATE NAS HDD IronWolf - 6 To
SEAGATE NAS HDD IronWolf - 6 To
SEAGATE NAS HDD IronWolf - 6 To

Je ne peux me connecter à Putty “Network error : Connection refused”, d’où l’impossibilité de partager les retours en texte.

fdisk -l | grep “Disk"

"The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Partition 2 does not start on physical sector boundary.”

Auriez-vous une piste de résolution de ce problème ?

Cdt
Eric

PascalHambourg · Juin 22, 2017, 12:49pm

Quel est le problème exactement avec le RAID 5 ?

Il n’y a pas de raison qu’un arrêt brutal de la machine ait endommagé la table de partition GPT primaire, ce n’est pas un endroit qui est souvent modifié. Par contre on peut rencontrer ce problème si on a créé une table de partition puis utilisé le disque entier (et non une partition) comme membre d’un ensemble RAID, ce qui est une erreur assez courante. Les positions de la table de partition GPT primaire et du superbloc RAID 1.2 se recouvrant, la création du superbloc RAID a partiellement écrasé la table de partition.

Edit : dans ce cas, ne pas restaurer la table de partition primaire car cela endommagerait le superbloc RAID et le disque ne pourrait plus être reconnu comme membre d’un ensemble RAID.

Tu ne peux pas envoyer les retours de commandes dans un fichier texte sur une clé USB ?

Il faudrait
La sortie complète de fdisk -l pour tous les disques du RAID.
La sortie de mdadm --examine --scan
Le contenu de /etc/mdadm/mdadm.conf
Le contenu de /proc/mdstat

Eric_fr75 · Juin 22, 2017, 3:27pm

(Je précise que je suis grand débutant sur Linux )

Ce qui me fait penser à un problème de Raid est concrètement dans mon cas d’utilisation OpenMediaVault ne va pas plus loin que le message d’erreur suivant :

(je ne peux poster que 2 images à la fois car nouvel utilisateur du forum désolé)

Eric_fr75 · Juin 22, 2017, 3:27pm

Voici les sorties que prise en photo hier et correspondent à peu près à celles que tu veux, je les compléterai dès que la machine sera à portée de clavier :

fdisk -l | grep “Disk”

PascalHambourg · Juin 22, 2017, 2:49pm

On ne voit pas la cause du passage en mode emergency. Il faudrait remonter plus haut avec shift-pageUp.
Que se passe-t-il si tu tapes control+d ?

Concernant la sortie de fdisk, elle me déconcerte. On ne voit aucune partition même sur sda qui est censé être le disque système.
Qu’il n’y ait pas de table de partition sur sdb et sdc ne me choque pas s’ils sont utilisés en entier pour le RAID (même si j’aurais plutôt recommandé d’utiliser une partition). Si sdd est aussi utilisé en entier pour le RAID, la présence d’une table de partition est une erreur de préparation, ou un reste d’une utilisation précédente qu’il vaudrait mieux effacer.

En tout cas l’ensemble raid md0 semble bien actif.

Pour monter une clé USB en console d’urgence :
Déterminer le nom de périphérique de la clé avec lsblk. Ce sera sûrement /dev/sde, et elle aura une partition /dev/sde1.
Montage de la clé :
mount /dev/sde1 /mnt
Copie d’un fichier sur la clé (exemples) :
cp /etc/mdadm/mdadm.conf /mnt cp /etc/fstab /mnt cp /proc/mdstat /mnt
Enregistrement de la sortie d’une commande dans un fichier sur la clé (exemples) :
fdisk -l > /mnt/fdisk.txt mdadm --examine --scan > /mnt/mdadm-scan.txt

Eric_fr75 · Juin 22, 2017, 6:22pm

Le Control+D me permet de continuer le chargement d’OMV qui semble se dérouler normalement. Mais impossible d’accéder à l’interface web ou encore de se connecter à l’interface web.

Voici la sortie fdisk (en attendant que je parvienne à envoyer les autres ligne sur la clé)

Disk /dev/sda: 119,2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdd2beedf

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 239855615 239853568 114,4G 83 Linux
/dev/sda2 239857662 250068991 10211330 4,9G 5 Extended
/dev/sda5 239857664 250068991 10211328 4,9G 82 Linux swap / Solaris

Disk /dev/sdb: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/sdd: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/sde: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B6A2273F-A413-4AB1-BAC2-5E53E9E0F9F7

Device Start End Sectors Size Type
/dev/sde1 34 262177 262144 128M Microsoft reserved

Disk /dev/md0: 10,9 TiB, 12002081636352 bytes, 23441565696 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk /dev/sdc: 962 MiB, 1008730112 bytes, 1970176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00124fa5

Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 2048 1970175 1968128 961M b W95 FAT32

cat /etc/mdadm/mdadm.conf

cat /proc/mdstat

PascalHambourg · Juin 22, 2017, 6:49pm

Quel est le problème pour envoyer les autres résultats sur la clé ?

D’après /proc/mdstat, le volume RAID md0 est actif mais en mode dégradé sur deux disques, sdb et sdd. Le disque sde n’y participe pas.

sde est justement le disque qui a une table de partition GPT. Cela pourrait empêcher sa reconnaissance comme membre RAID.

Apparemment ce disque a été utilisé avec Windows avant (j’espère) de servir au RAID. Pour supprimer ces traces, la première étape est de les identifier avec :
wipefs /dev/sde
Cela affiche les signatures présentes et leurs position. Il faudra sélectivement effacer la signature GPT (du secteur 1) mais pas la signature RAID (du secteur 8), en espérant qu’elle n’a pas déjà été effacée par une restauration de la table de partition primaire à partir de la table secondaire située à la fin du disque.

Néanmoins cela ne devrait pas avoir de conséquences autre que des performances dégradées sur le fonctionnement de l’ensemble RAID 5 qui est prévu pour fonctionner avec un disque manquant.

Note : les noms des disques peuvent changer d’un démarrage à l’autre car ils sont attribués dans l’ordre de découverte. Sur les photos précédentes, les disques de 6 To étaient sdb, sdc et sdd ; maintenant ils sont sdb, sdd et sde alors que sdc est la clé USB. C’est un peu étonnant parce qu’habituellement les périphériques de stockage USB sont détectés après les disques SATA, mais visiblement l’inverse peut arriver. Je suppose que la clé était déjà branchée lors du démarrage ? Ce n’est pas nécessaire. Bref, toujours vérifier quel nom correspond à quel disque et ne pas se fier aux noms du précédent démarrage.

Eric_fr75 · Juin 23, 2017, 10:09am

J’ai du mal m’y prendre avec l’écriture sur la clé usb. Pour préciser le problème j’ai bien réussi à cibler la clé et à exporter le résultat du fdisk par exemple, mais d’autres txt générés étaient quant à eux vides. J’avais correctement repéré l’emplacement de la clé avec la commande fdisk -l | grep “Disk” si j’ai bonne mémoire.

Les 3 disques sont neufs et n’ont pas été utilisés sur Windows au préalable.

[quote=“PascalHambourg, post:8, topic:73752”]
Néanmoins cela ne devrait pas avoir de conséquences autre que des performances dégradées sur le fonctionnement de l’ensemble RAID 5 qui est prévu pour fonctionner avec un disque manquant.
[/quote] Je ne comprends pas non plus le fait qu’OMV ne me laisse pas accéder à l’interface web. A noter que j’y parviens si je débranche avant le démarrage le disque problématique. Mais dans ce cas de figure je n’accède pas au données du Raid même si les 2 disques branchés de ce dernier son visibles dans l’interface.

PascalHambourg · Juin 23, 2017, 10:42am

N’oublie pas de démonter le système de fichiers de la clé avant de la débrancher :
sync umount /mnt

J’ai besoin du contenu de /etc/fstab pour savoir comment est censé être monté le contenu de l’ensemble RAID.
La sortie de la commande blkid sera également utile ainsi que toutes les autres commandes déjà mentionnées dans mes différents messages.

La partition de type “Microsoft Reserved” ne s’est pas créée toute seule, et elle est typiquement créée lors de l’installation de Windows sur un disque au format GPT (en mode EFI).

Eric_fr75 · Juin 24, 2017, 7:25am

Voici les sorties :

/etc/mdadm/mdadm.conf

[code] # mdadm.conf

Please refer to mdadm.conf(5) for information about this file.

by default, scan all partitions (/proc/partitions) for MD superblocks.

alternatively, specify devices to scan, using wildcards if desired.

Note, if no DEVICE line is present, then “DEVICE partitions” is assumed.

To avoid the auto-assembly of RAID devices a pattern that CAN’T match is

used if no RAID devices are configured.

DEVICE partitions

auto-create devices with Debian standard permissions

CREATE owner=root group=disk mode=0660 auto=yes

automatically tag new arrays as belonging to the local system

HOMEHOST

definitions of existing MD arrays

ARRAY /dev/md0 metadata=1.2 name=openmediavault:data UUID=bdea5781:fef18b66:6a3166c8:d6ec3fad[/code]

/etc/fstab

[code] # /etc/fstab: static file system information.

Use ‘blkid’ to print the universally unique identifier for a

device; this may be used with UUID= as a more robust way to name devices

that works even if disks are added and removed. See fstab(5).

/ was on /dev/sda1 during installation

UUID=a46dc94f-d2a0-44a9-be3d-6534fdd4ef7b / ext4 errors=remount-ro 0 1

swap was on /dev/sda5 during installation

UUID=d43c8706-d52c-4597-b93a-613fc622d145 none swap sw 0 0
tmpfs /tmp tmpfs defaults 0 0

>>> [openmediavault]

/dev/disk/by-id/md-name-openmediavault:data /srv/dev-disk-by-id-md-name-openmediavault-data ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2

<<< [openmediavault][/code]

/proc/mdstat

[code] Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb[0] sdd[2]
11720782848 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [U_U]
bitmap: 10/44 pages [40KB], 65536KB chunk

unused devices: [/code]

fdisk -l

[code] Disk /dev/sdb: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/sda: 119,2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdd2beedf

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 239855615 239853568 114,4G 83 Linux
/dev/sda2 239857662 250068991 10211330 4,9G 5 Extended
/dev/sda5 239857664 250068991 10211328 4,9G 82 Linux swap / Solaris

Disk /dev/sdd: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B6A2273F-A413-4AB1-BAC2-5E53E9E0F9F7

Device Start End Sectors Size Type
/dev/sdd1 34 262177 262144 128M Microsoft reserved

Disk /dev/sdc: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/md0: 10,9 TiB, 12002081636352 bytes, 23441565696 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk /dev/sdf: 962 MiB, 1008730112 bytes, 1970176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00124fa5

Device Boot Start End Sectors Size Id Type
/dev/sdf1 * 2048 1970175 1968128 961M b W95 FAT32
[/code]

mdadm --examine --scan

blkid

/dev/sdb: UUID="bdea5781-fef1-8b66-6a31-66c8d6ec3fad" UUID_SUB="5228664a-20d1-3bbd-f6e0-53f30d82d0bf" LABEL="openmediavault:data" TYPE="linux_raid_member" /dev/sda1: UUID="a46dc94f-d2a0-44a9-be3d-6534fdd4ef7b" TYPE="ext4" PARTUUID="dd2beedf-01" /dev/sda5: UUID="d43c8706-d52c-4597-b93a-613fc622d145" TYPE="swap" PARTUUID="dd2beedf-05" /dev/sdd: UUID="bdea5781-fef1-8b66-6a31-66c8d6ec3fad" UUID_SUB="45f17caa-caf2-18c8-b73a-05fc62ba5390" LABEL="openmediavault:data" TYPE="linux_raid_member" /dev/md0: LABEL="data" UUID="40aaf943-537c-4184-9d36-f37ee244b0ff" TYPE="ext4" /dev/sdc: UUID="bdea5781-fef1-8b66-6a31-66c8d6ec3fad" UUID_SUB="e5f75494-2b65-e546-783f-dd4dc4614d29" LABEL="openmediavault:data" TYPE="linux_raid_member" /dev/sdf1: LABEL="USB" UUID="1CCE-38C4" TYPE="vfat" PARTUUID="00124fa5-01"

PascalHambourg · Juin 24, 2017, 8:23am

J’ai oublié de spécifier l’option --verbose dans la commande mdadm pour afficher la liste des membres des ensembles. Mais la sortie de la commande blkid indique bien la présence de superblocs RAID sur les trois disques de 6 To, y comprise celui qui a une table de partition.

D’après /proc/mdstat les deux membres actifs sont sdb et sdd (il manque sdc) mais d’après fdisk le disque partitionné est sdd. Ça ne correspond pas avec les informations précédentes.
As-tu exécuté toutes ces commandes dans une même session ? Il le faut car les noms des disques changent à chaque démarrage.

/etc/fstab indique que l’ensemble RAID contient un système de fichiers ext4 unique censé être monté sur /srv/dev-disk-by-id-md-name-openmediavault-data. Tu peux vérifier avec mount et df s’il est bien monté, et afficher son contenu avec
ls -a /srv/dev-disk-by-id-md-name-openmediavault-data

Si le volume RAID n’est pas monté, le système de fichiers est peut-être resté dans un état incohérent suite à l’arrêt brutal, mais il devrait y avoir un message d’erreur lors du démarrage. Il faudra le réparer avec fsck mais je préfère faire cela après avoir remis l’ensemble RAID en fonctionnement nominal sur trois membres actifs.

En premier je suggère de supprimer la table de partition GPT afin de lever le doute sur son incidence.
Avec fdisk -l, identifier le disque de 6 To qui a une table de partition GPT.
Exécuter wipefs avec en argument le nom /dev/sd* du disque rapporter la sortie ici.

Eric_fr75 · Juin 24, 2017, 8:58am

Je ne me souviens plus si j’ai vérifié les disques sous Windows, mais dans ce cas il est etonnant que l’erreur ne concerne qu’un disque sur trois non ?

Toutes les sorties de mon message précédent ont été effectuées sur la même session.
Là je viens d’en démarrer une nouvelle : ma clé USB est sur le sde.

md0 est visible avec les commande et les dossiers sont bien affichés par mount et df

C’est sdb qui possède la table GPT n’est-ce pas ?
fdisk -l

Disk /dev/sda: 119,2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdd2beedf

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048 239855615 239853568 114,4G 83 Linux
/dev/sda2       239857662 250068991  10211330   4,9G  5 Extended
/dev/sda5       239857664 250068991  10211328   4,9G 82 Linux swap / Solaris

Disk /dev/sdb: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/sdc: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/sdd: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B6A2273F-A413-4AB1-BAC2-5E53E9E0F9F7

Device     Start    End Sectors  Size Type
/dev/sdd1     34 262177  262144  128M Microsoft reserved


Disk /dev/md0: 10,9 TiB, 12002081636352 bytes, 23441565696 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk /dev/sde: 962 MiB, 1008730112 bytes, 1970176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00124fa5

Device     Boot Start     End Sectors  Size Id Type
/dev/sde1  *     2048 1970175 1968128  961M  b W95 FAT32

mdadm --detail --scan --verbose

ARRAY /dev/md0 level=raid5 num-devices=3 metadata=1.2 name=openmediavault:data UUID=bdea5781:fef18b66:6a3166c8:d6ec3fad
   devices=/dev/sdb,/dev/sdd

PascalHambourg · Juin 24, 2017, 9:30am

Non, c’est sdd, avec une partition sdd1.
Ce qui ne semble pas empêcher mdadm de le reconnaître comme un membre de l’ensemble RAID mais pas sdc, ce que je ne comprends pas.
Voyons ce que qu’affiche
mdadm --examine --verbose /dev/sd[bcd]

Eric_fr75 · Juin 24, 2017, 9:44am

mdadm --examine --verbose /dev/sd[bcd]

[code]/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : bdea5781:fef18b66:6a3166c8:d6ec3fad
Name : openmediavault:data (local to host openmediavault)
Creation Time : Tue May 2 22:18:36 2017
Raid Level : raid5
Raid Devices : 3

Avail Dev Size : 11720783024 (5588.90 GiB 6001.04 GB)
Array Size : 11720782848 (11177.81 GiB 12002.08 GB)
Used Dev Size : 11720782848 (5588.90 GiB 6001.04 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=176 sectors
State : clean
Device UUID : 5228664a:20d13bbd:f6e053f3:0d82d0bf

Internal Bitmap : 8 sectors from superblock
Update Time : Sat Jun 24 11:42:39 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 9a9e035e - correct
Events : 7382

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : Active device 0
Array State : A.A (‘A’ == active, ‘.’ == missing, ‘R’ == replacing)
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : bdea5781:fef18b66:6a3166c8:d6ec3fad
Name : openmediavault:data (local to host openmediavault)
Creation Time : Tue May 2 22:18:36 2017
Raid Level : raid5
Raid Devices : 3

Avail Dev Size : 11720783024 (5588.90 GiB 6001.04 GB)
Array Size : 11720782848 (11177.81 GiB 12002.08 GB)
Used Dev Size : 11720782848 (5588.90 GiB 6001.04 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=176 sectors
State : clean
Device UUID : e5f75494:2b65e546:783fdd4d:c4614d29

Internal Bitmap : 8 sectors from superblock
Update Time : Thu Jun 15 23:24:14 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 32346953 - correct
Events : 6662

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : Active device 1
Array State : AAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing)
/dev/sdd:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : bdea5781:fef18b66:6a3166c8:d6ec3fad
Name : openmediavault:data (local to host openmediavault)
Creation Time : Tue May 2 22:18:36 2017
Raid Level : raid5
Raid Devices : 3

Avail Dev Size : 11720783024 (5588.90 GiB 6001.04 GB)
Array Size : 11720782848 (11177.81 GiB 12002.08 GB)
Used Dev Size : 11720782848 (5588.90 GiB 6001.04 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=176 sectors
State : clean
Device UUID : 45f17caa:caf218c8:b73a05fc:62ba5390

Internal Bitmap : 8 sectors from superblock
Update Time : Sat Jun 24 11:42:39 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : dec68013 - correct
Events : 7382

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : Active device 2
Array State : A.A (‘A’ == active, ‘.’ == missing, ‘R’ == replacing)[/code]

PascalHambourg · Juin 24, 2017, 10:01am

Update Time : Thu Jun 15 23:24:14 2017
sdc n’est plus synchronisé avec les deux autres, son nombre d’événements (“Events”) est en retard par rapport aux deux autres. Il n’est plus un membre actif de l’ensemble RAID depuis le 15 juin. Est-ce ce jour-là que la coupure de courant s’est produite ? Sinon, cela pourrait être dû à une défaillance du disque. Si smartctl est disponible, tu peux récupérer le statut SMART avec

smartctl -a /dev/sdc

Si le disque est en bon état (RAW_VALUE à 0 pour les attributs Current_Pending_Sector et Offline_Uncorrectable, pas d’erreur dans les logs), pour le réintégrer et lancer la resynchronisation :

mdadm --add /dev/md0 /dev/sdc

Avec des disques aussi gros, cela va prendre du temps. Tu peux suivre l’avancement de la reconstruction dans /proc/mdstat.

Eric_fr75 · Juin 24, 2017, 10:21am

Oui c’est à ce moment là.

Smart semble indiquer que sdc est en bonne santé. Ce qui est rassurant pour des disques “spécial Nas” avec 5 jours de mise sous tension au compteur.

smartctl -a /dev/sdc

=== START OF INFORMATION SECTION ===
Device Model: ST6000VN0041-2EL11C
Serial Number: ZA14W771
LU WWN Device Id: 5 000c50 092be80ad
Firmware Version: SC61
User Capacity: 6 001 175 126 016 bytes [6,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-3 T13/2161-D revision 5
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Jun 24 12:07:36 2017 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: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
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: ( 575) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
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: ( 565) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x50bd) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table 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 081 064 044 Pre-fail Always - 125415599
3 Spin_Up_Time 0x0003 085 084 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 71
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 074 060 045 Pre-fail Always - 25346796
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 134 (165 217 0)
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 72
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 056 050 040 Old_age Always - 44 (Min/Max 29/44)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 148
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 30
193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 143
194 Temperature_Celsius 0x0022 044 050 000 Old_age Always - 44 (0 19 0 0 0)
195 Hardware_ECC_Recovered 0x001a 010 001 000 Old_age Always - 125415599
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 - 116 (221 180 0)
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 2135527361
242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 13111758664

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]

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]

PascalHambourg · Juin 24, 2017, 10:46am

Alors tu peux lancer la reconstruction.

Edit : A priori la table de partition GPT sur sdd est donc une fausse piste, mais il serait quand même bon de la supprimer en tant que source de confusion et de perte de temps. De préférence après la fin de la reconstruction.

Eric_fr75 · Juin 24, 2017, 11:01am

Commande mdadm --add /dev/md0 /dev/sdc lancé.

/proc/mdstat

[code]Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdc[1] sdb[0] sdd[2]
11720782848 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
bitmap: 0/44 pages [0KB], 65536KB chunk

unused devices:
[/code]

Comment lancer la reconstruction ?
Je n’ai pas accès à l’interface Web d’OMV. Dois’je passer par un redémarrage ?

PascalHambourg · Juin 24, 2017, 11:11am

Apparemment sdc a été réintégré sans qu’il soit nécessaire de le resynchroniser, ou alors la resynchronisation a été très rapide car il y avait peu de différences. Tant mieux.

Tu peux redémarrer pour voir ce qui se passe et vérifier que

l’ensemble RAID md0 est activé avec 3 membres actifs sur 3
le système de fichiers de md0 est monté sur /srv/…

Pour le reste, je ne connais pas OMV et je ne sais pas ce qui peut empêcher son interface web de démarrer.

Eric_fr75 · Juin 24, 2017, 11:32am

Redémarrage effectué.
J’obtiens l’erreur de départ : Failed to start Enable File System Quotas

fdisk indique que la table le problème de corruption de la table GPT.

Le Raid semble prendre en compte les 3 disques.

/proc/mdstat

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb[0] sdd[2] sdc[1]
      11720782848 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/44 pages [0KB], 65536KB chunk

unused devices: <none>

fdisk -l | grep “Disk”

Disk /dev/sda: 119,2 GiB, 128035676160 bytes, 250069680 sectors Disklabel type: dos Disk identifier: 0xdd2beedf Disk /dev/sdb: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors Disk /dev/sdc: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors Disk /dev/sdd: 5,5 TiB, 6001175126016 bytes, 11721045168 sectors Disklabel type: gpt Disk identifier: B6A2273F-A413-4AB1-BAC2-5E53E9E0F9F7 Disk /dev/md0: 10,9 TiB, 12002081636352 bytes, 23441565696 sectors Disk /dev/sde: 962 MiB, 1008730112 bytes, 1970176 sectors Disklabel type: dos Disk identifier: 0x00124fa5