Disque en lecture seule

Support Debian
#1

Bonjour à tous,

ça fait un moment, un serveur physique (dédié) en RAID1 tombe en pane à cause du disque qui se met en lecture seule, je n’arrive pas à comprendre la cause.

Au niveau des logs il y a :
… kernel: [ 366.761948] attempt to access beyond end of device
… kernel: [ 366.766379] md1: rw=0, want=486139248, limit=486139136

En netboot, j’ai lancé un e2fsck et resize2fs et ça n’a pas réglé le problème.

Pourrir-vous m’aider, c’est urgent ?

Je vous remercie par avance.

Pour info : sur le serveur il y a deux disques de 500Go en raid1 mais les raid1 n’est que sur 256Go :

# fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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
Disk identifier: 0x56c32dd7

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1      204799      102399+  83  Linux
/dev/sda2          204800     2252799     1024000   82  Linux swap / Solaris
/dev/sda3         2252800   488392064   243069632+  83  Linux

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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
Disk identifier: 0x56017d73

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1      204799      102399+  83  Linux
/dev/sdb2          204800     2252799     1024000   82  Linux swap / Solaris
/dev/sdb3         2252800   488392064   243069632+  83  Linux

Disk /dev/md1: 248.9 GB, 248903237632 bytes
2 heads, 4 sectors/track, 60767392 cylinders, total 486139136 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
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table

Disk /dev/md0: 104 MB, 104726528 bytes
2 heads, 4 sectors/track, 25568 cylinders, total 204544 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
Disk identifier: 0x00000000

    Device Boot      Start         End      Blocks   Id  System

Disk /dev/md2: 1047 MB, 1047986176 bytes
2 heads, 4 sectors/track, 255856 cylinders, total 2046848 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
Disk identifier: 0x00000000

Disk /dev/md2 doesn't contain a valid partition table

# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sdb2[2] sda2[1]
      1023424 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      102272 blocks [2/2] [UU]

md1 : active raid1 sda3[0] sdb3[1]
      243069568 blocks [2/2] [UU]
#2

Que dit

mdadm --examine /dev/sd[ab]3
mdadm --detail /dev/md1
tune2fs -l /dev/md1
#3

Merci pour votre réponse !

Voici les résultas des commandes :

# mdadm --examine /dev/sda3
/dev/sda3:
          Magic : a92b4efc
        Version : 0.90.03
           UUID : a6205101:62e6671c:01c4e730:637130c0
  Creation Time : Fri Feb  1 18:26:20 2013
     Raid Level : raid1
  Used Dev Size : 243069568 (231.81 GiB 248.90 GB)
     Array Size : 243069568 (231.81 GiB 248.90 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1

    Update Time : Mon Sep 24 16:24:49 2018
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : d29a8f44 - correct
         Events : 36512


      Number   Major   Minor   RaidDevice State
this     0       8        3        0      active sync   /dev/sda3

   0     0       8        3        0      active sync   /dev/sda3
   1     1       8       19        1      active sync   /dev/sdb3

# mdadm --examine /dev/sdb3
/dev/sdb3:
          Magic : a92b4efc
        Version : 0.90.03
           UUID : a6205101:62e6671c:01c4e730:637130c0
  Creation Time : Fri Feb  1 18:26:20 2013
     Raid Level : raid1
  Used Dev Size : 243069568 (231.81 GiB 248.90 GB)
     Array Size : 243069568 (231.81 GiB 248.90 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1

    Update Time : Mon Sep 24 16:24:40 2018
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : d29a8f4d - correct
         Events : 36512


      Number   Major   Minor   RaidDevice State
this     1       8       19        1      active sync   /dev/sdb3

   0     0       8        3        0      active sync   /dev/sda3
   1     1       8       19        1      active sync   /dev/sdb3

# mdadm --detail /dev/md1
/dev/md1:
        Version : 0.90
  Creation Time : Fri Feb  1 18:26:20 2013
     Raid Level : raid1
     Array Size : 243069568 (231.81 GiB 248.90 GB)
  Used Dev Size : 243069568 (231.81 GiB 248.90 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Mon Sep 24 16:27:06 2018
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : a6205101:62e6671c:01c4e730:637130c0
         Events : 0.36511

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3

Je ne maitrise pas trop mdadm mais il me semble que d’après les résultats le raid est en bonne état

#4 
# tune2fs -l /dev/md1
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          0f2b6dc0-2821-437f-8954-4c280e5143a3
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30392320
Block count:              60767408
Reserved block count:     3038370
Free blocks:              25726755
Free inodes:              30182458
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Fri Feb  1 18:16:29 2013
Last mount time:          Fri Sep 21 15:23:23 2018
Last write time:          Fri Sep 21 14:28:53 2018
Mount count:              2
Maximum mount count:      28
Last checked:             Fri Sep 21 14:21:05 2018
Check interval:           15552000 (6 months)
Next check after:         Wed Mar 20 13:21:05 2019
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       12746768
Default directory hash:   tea
Directory Hash Seed:      fac808b4-2d04-4cad-9e56-c3798b242883
Journal backup:           inode blocks
#5

L’ensemble RAID /dev/md1 semble en bon état mais la taille déclarée du système de fichiers qu’il contient est légèrement supérieure à la taille utile de l’ensemble RAID. Quand le contenu est plus grand que le contenant et qu’on cherche à accéder à la partie qui dépasse, ça fait des problèmes, forcément…

Que s’est-il passé avec e2fsck et resize2fs ? D’après mes souvenirs ils auraient dû afficher une erreur et sont incapables de corriger ce type de problème. Une solution consiste à agrandir l’ensemble RAID.

Je constate que la taille du système de fichier est exactement la taille des partitions RAID brutes (supérieure à la taille utile de l’ensemble RAID pour y loger le superbloc RAID en plus des données). J’observe aussi que lesdites partitions RAID sont marquées de type “Linux” au lieu de “RAID” dans les tables de partitions, ce qui n’a pas de conséquence pratique mais combiné à la première constatation me fait envisager l’hypothèse que c’était initialement une partition ext3 ou ext4 normale qui a été (mal) convertie en RAID.

Sinon, comment en es-tu arrivé là ? Y a t-il eu des opérations de redimensionnement ?

#6

Merci pour votre message.

Historiquement, il y a eu deux disque en raid1 de taille identique (256G les deux), à un moment il y a eu un problème sur un des disques et il est remplacé par un disque de 500Go par l’hébergeur (qui m’a informé qu’il y a pas de soucis de faire ainsi !) .
Et une autre fois, il y a eu un problème sur le deuxième disque de 256Go et il a était remplacé par un de 500Go.

C’est pour cela que le serveur à deux disques de 500Go mais juste 256Go partitionnées (utilisé).

Le serveur il a marché pendant une année comme ça et récemment il y a eu l’erreur et le disque est passé en lecture seule (sans aucune intervention au préalable liée au système de fichier) .

Personnellement je pense c’est lié à un problème matériel, plus que logiciel. d’après le résultat de test log smart, il me semble que c’est le disque sdb qui pose problème (ci-joint le résultat des tests) . Pourriez-vous me confirmer ça ? merci par avance.

smartctl-long-sda.log (4,8 Ko)
smartctl-long-sdb.log (4,9 Ko)

#7

En effet sdb a des secteurs défectueux, mais d’une part cela n’explique pas l’incohérence entre les tailles de md1 et de son système de fichiers, et d’autre part le premier secteur illisible détecté par l’auto-test SMART (488434617) est situé au-delà de la fin de la dernière partition (488392064).

Les logs du noyau cités dans ton message initial n’ont rien à voir avec des erreurs de secteurs défectueux.

#8

Merci bcp pour vos réponses PascalHambourg,

Effectivement, Les logs du noyau cités dans ton message initial n’ont rien à voir avec des erreurs de secteurs défectueux, car ce n’est pas la première fois qu’il fait ça.

La semaine passé, il y a eu le même problème et après deux passe de e2ckfs et resize et redémarrage du serveur, le disque et retourné à un état stable avec lecture/écriture . J’ai libéré de l’espace sur le serveur .
Le serveur a refait le coups cette semaine. J’ai l’impression à chaque fois qu’il arrive à écrire sur un secteur et se trouve en erreur.

#9

Qu’il fait quoi ? Je ne vois pas le rapport entre les deux parties de la phrase.

Quoi qu’il en soit, le disque sdb a des secteurs défectueux et devrait être remplacé. Au minimum il faudrait utiliser badblocks pour identifier tous les secteurs illisibles et vérifier s’il y en a dans les zones occupées par les partitions.
Il faut aussi régler le problème d’incohérence des tailles.

Le système de fichiers était très rempli ? Je soupçonne que le problème se produit quand le système essaie d’écrire à la fin du système de fichiers quand celui-ci n’a plus beaucoup d’espace libre.

#10

désolée faute de copier/coller. Je voulais dire ce n’est pas la première fois que le serveur se trouvent avec un disque en lecture seule, après lancement de e2fsck et reboot plusieurs fois le disque devient à nouveau en lecture/écriture.

Les logs que j’ai mis tout en haut, sont les dernières erreurs.

#11

S’il n’y a pas d’erreurs ATA concernant les secteurs illisibles lorsque le système de fichiers passe en lecture seule, le problème ne vient pas de là. Mais il vaudrait mieux quand même remplacer le disque.

D’après mon expériencer e2fsck ne peut pas réparer l’incohérence entre les tailles de contenant et de contenu. Il faut réduire le système de fichiers ou agrandir l’ensemble RAID.

#12

Ce qui m’entonne comment le serveur a pu marché pendant longtemps comme ça et d’un seul cout il a un problème file-système, j’ai l’impression, ça arrive à chaque fois quant le disque est presque 80% d’utilisation, c’est pour ça je pense que le problème vient aussi du disque.

#13

C’est exactement ce que j’écrivais. C’est à ce moment que le système de fichiers va essayer d’utiliser les blocs situés au-delà de la fin de l’ensemble RAID. Inutile de tourner autour du pot : il faut réparer cette incohérence de tailles.

#14

Je vous remercie pour réponses !

J’ai déjà mentionné ça à l’hébergeur même quant il ont mis deux disques de taille différentes dans un raid1 et ils ont dit qu’ils ont l’habitude et pas de problème (et j’avoue moi je ne suis pas trop à l’aise pour la résolution des problèmes de disques :frowning: ).

Historiquement le serveur avait deux disque 256Go, puis deux de taille différentes (500Go et 256Go) et il a resté en marche pendant un bon moment puis le disque de 256Go tombait en panne et il est remplacé par un de 500Go (maintenant deux disques de 500Go) mais sans changement de partitionnement (car à chaque fois on appliquait la table de partition existante sur le nouveau avant de reconstruire le raid ), c’est pour cela le serveur se retrouve avec les partitions :

  • sda1 (sdb1) -> md0
  • sda2 (sdb2) : swap -> md2
  • sda3 , sdb3 -> md1 ( Array Size : 243069568 (231.81 GiB 248.90 GB))
  • Le reste du disque non partitionné

Les résultats des commandes “mdadm --examine /dev/sda3”, “mdadm --examine /dev/sdb3” et “mdadm --detail /dev/md1” (cf. résultat ci-dessus), montre que Used Dev Size et Array Size ont les mêmes valeurs pour les sda3, sdb3 et aussi pour md1 qui les groupe. donc, sauf erreur, malgré ce problème de taille je ne comprends pas pourquoi le serveur essaye décrire au-delà du la taille limite d’un seul cout même s’il reste encore plus de 40Go libre, vu que la partition raid (md1) a la même limite que la limite des deux partitions sda3 et sdb3.

Pour moi il y a deux problèmes :

  • problème de taille : soft
  • problème de disque : hard (d’après les résultat de test smart)
    Et dans tous les cas il faut changer de disque (le serveur marche à l’état actuel en mode dégradé ( pic de charge cpu) et avec l’erreur " md1: rw=0, want=486139248, limit=486139136" dans les logs).
#15

Bonjour,

Je dis ça pour ce que ça vaut ; pour l’espace disque, il n’y a peut-être plus assez d’inœuds disponibles.

Semble dire qu’il y en a suffisamment.

Free inodes: 30182458

# df -i

Je suis le sujet car je suis intéressé de voir comment vous allez procéder pour agrandir le RAID (md1)

Le reste suivra naturellement.

#16

Pouvez vous m’aider pour la réparation de cette incohérence, je n’ai pas d’expérience sur le sujet et d’après mes recherches c’est une opération risquée et je flippe un peu vu que c’est un serveur de prod.

Merci beaucoup par avance.

@ r2mi une fois réussi, je mettrai les étapes.

#17

Le changement de disques n’explique pas l’incohérences entre les tailles de l’ensemble RAID et du système de fichiers. Le serveur a vraiment toujours été en RAID ?

Parce que le système de fichiers ext* dit qu’il est plus grand que l’ensemble RAID.

Je vois deux méthodes : la risquée et la longue (et risquée aussi, mais pas de la même façon). Pour la première, il faut quand même que je vérifie avant.

Edit : j’ai fait des essais, et en fait il y a deux méthodes possibles rapides et peu risquées :

  • réduire le système de fichiers à la taille de l’ensemble RAID, mais il faut le démonter donc impossible depuis le système si c’est la racine.
  • agrandir les partitions puis l’ensemble RAID, faisable lorsqu’il est monté.

Mais comme tu l’as écrit, il faudrait régler le problème du disque défectueux.

En attendant peux-tu poster le résultat des commandes suivantes :

tune2fs -l /dev/md0
cat /proc/swaps
df -hT

Et aussi le contenu du fichier badblocks.txt après avoir exécuté la commande suivante :

badblocks -svo badblocks.txt /dev/sdb
#18

Le disque défectueux est remplacé et c’est le moment de la vérité :wink: je j’avoue je flippe et il faut garder le serveur disponible. Je pense le mieux c’est la deuxième solution et la moins risquée ?

Sauf erreur, je comprends par “/dev/sda3 2252800 488392064 243069632+ 83 Linux” de la sortie “fdisk -l …” (cf. ci-dessous) que la partition “sda3” est limitée par le secteur 488392064 mais le dernier bloc est resté à 243069632 (lié à la limite de /dev/md1 qui est à 243069568 fixée avant par les anciens disques de 256Go) et il faut corriger cette taille de bloc. est ce bien ça ? si oui, pouvez vous m’aider? je regarde de mon coté mais c’est la première fois que je fais de telle opération et un deuxième avis ça rassure? merci d’avance.

A l’état actuel voici l’état des partitions des disques :

1. /dev/sda (qui est toujours dans le raid1)

# fdisk -l /dev/sda                  (qui est toujours dans le raid1)

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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
Disk identifier: 0x56c32dd7

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1      204799      102399+  83  Linux
/dev/sda2          204800     2252799     1024000   82  Linux swap / Solaris
/dev/sda3         2252800   488392064   243069632+  83  Linux

# sfdisk -d /dev/sda > sda.out
# cat sda.out
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=        1, size=   204799, Id=83, bootable
/dev/sda2 : start=   204800, size=  2048000, Id=82
/dev/sda3 : start=  2252800, size=486139265, Id=83
/dev/sda4 : start=        0, size=        0, Id= 0

2. /dev/sdb (le nouveau disque, pas encore dans le raid1)

J’ai essayé d’appliquer les partitions des “sda” et voici la sortie :
# sfdisk /dev/sdb < sda.out
Checking that no-one is using this disk right now …
OK

Disk /dev/sdb: 60801 cylinders, 255 heads, 63 sectors/track

sfdisk: ERROR: sector 0 does not have an msdos signature
 /dev/sdb: unrecognized partition table type
Old situation:
No partitions found
New situation:
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sdb1   *         1    204799     204799  83  Linux
/dev/sdb2        204800   2252799    2048000  82  Linux swap / Solaris
/dev/sdb3       2252800 488392064  486139265  83  Linux
/dev/sdb4             0         -          0   0  Empty
Warning: partition 1 does not end at a cylinder boundary
Warning: partition 2 does not start at a cylinder boundary
Warning: partition 2 does not end at a cylinder boundary
Warning: partition 3 does not start at a cylinder boundary
Successfully wrote the new partition table

Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
#19

Pas exactement.
243069632+ est la taille de la partition en “blocs” de 1 Kio (1024 octets, soit deux secteurs de 512 octets), le + indiquant que c’est un arrondi par défaut, le nombre de secteurs (de 512 octets) de la partition (488392064 - 2252800 + 1 = 486139265 comme l’affiche sfdisk) étant impair.
La taille du système de fichiers n’est pas visible dans la table de partition.

Il faut corriger la taille de la partition, c’est-à-dire la position du secteur de fin de celle-ci. Tu peux en profiter pour utiliser tout l’espace libre non alloué des disques si tu veux, à moins que tu préfères garder cet espace pour un autre usage.

Mais il y a un mystère que je ne comprends pas : dans tous mes essais, le noyau refuse de monter un système de fichiers ext* dont la taille déclarée dépasse la taille de son contenant.

#20

Je m’inquiète @yfi … Je crains qu’il y ait eu un problème.

@PascalHambourg, pourquoi cette mention ?

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes:
dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

Quelle est l’utilité de cette commande ? Il faudra bien installer Grub sur le nouveau sdb ?

Et aussi :

C’est pas important ? On peut l’ignorer ? Ça implique quoi ?

Elle a bien été corrigée par la duplication du schéma de partitionnement ?
édition : ça ne change en rien le contenant RAID md1 demeurant plus petit que les partitions sda3 / sdb3.

Je ne vois pas vraiment comment agrandir sda3 et sdb3 avec le système en fonctionnement…

Pour ça, il faut bien que le nouveau disque sdb ait exactement la même taille que sda ?

Suffit pour indiquer que les deux disques ont des capacités identiques ?
.

J’ai bien lu que @yfi n’était pas assuré pour faire les manipulations et j’ai peur pour lui et le serveur en production.

Pourvu que les choses se passent bien.
J’essaie de suivre.