Comment remonter une lecture / écriture ext3 fs après l'avoir montée en lecture seule à partir d'une erreur de disque?

18

C'est un problème relativement courant lorsqu'un problème survient dans un SAN pour ext3 pour détecter les erreurs d'écriture sur le disque et remonter le système de fichiers en lecture seule. C'est très bien, seulement lorsque le SAN est réparé, je ne peux pas comprendre comment re-monter le système de fichiers en lecture-écriture sans redémarrer.

Voir:

[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:1 sdb 8:16  [active][ready]
\_ 2:0:0:1 sdc 8:32  [active][ready]
[root@localhost ~]# mount /dev/mapper/mpath0 /mnt/foo
[root@localhost ~]# touch /mnt/foo/blah

Très bien, maintenant je tire le LUN de dessous.

[root@localhost ~]# touch /mnt/foo/blah
[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system
[root@localhost ~]# tail /var/log/messages
Mar 18 13:17:33 localhost multipathd: sdb: tur checker reports path is down
Mar 18 13:17:34 localhost multipathd: sdc: tur checker reports path is down
Mar 18 13:17:35 localhost kernel: Aborting journal on device dm-2.
Mar 18 13:17:35 localhost kernel: Buffer I/O error on device dm-2, logical block 1545
Mar 18 13:17:35 localhost kernel: lost page write due to I/O error on dm-2
Mar 18 13:17:36 localhost kernel: ext3_abort called.
Mar 18 13:17:36 localhost kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb:   Detected aborted journal                      
Mar 18 13:17:36 localhost kernel: Remounting filesystem read-only

Il ne pense que sa lecture seule, en réalité ce n'est même pas là.

[root@localhost ~]# multipath -ll
sdb: checker msg is "tur checker reports path is down"
sdc: checker msg is "tur checker reports path is down"
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=0][hwhandler=0][rw]
\_ round-robin 0 [prio=0][enabled]
 \_ 1:0:0:1 sdb 8:16  [failed][faulty]
 \_ 2:0:0:1 sdc 8:32  [failed][faulty]
[root@localhost ~]# ll /mnt/foo/
ls: reading directory /mnt/foo/: Input/output error
total 20
-rw-r--r-- 1 root root     0 Mar 18 13:11 bar

Comment il se souvient encore de la présence de ce fichier "bar" ... mystère, mais pas important pour le moment. Maintenant, je présente à nouveau le LUN:

[root@localhost ~]# tail /var/log/messages
Mar 18 13:23:58 localhost multipathd: sdb: tur checker reports path is up
Mar 18 13:23:58 localhost multipathd: 8:16: reinstated
Mar 18 13:23:58 localhost multipathd: mpath0: queue_if_no_path enabled
Mar 18 13:23:58 localhost multipathd: mpath0: Recovered to normal mode
Mar 18 13:23:58 localhost multipathd: mpath0: remaining active paths: 1
Mar 18 13:23:58 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:58 localhost multipathd: dm-2: devmap already registered
Mar 18 13:23:59 localhost multipathd: sdc: tur checker reports path is up
Mar 18 13:23:59 localhost multipathd: 8:32: reinstated
Mar 18 13:23:59 localhost multipathd: mpath0: remaining active paths: 2
Mar 18 13:23:59 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:59 localhost multipathd: dm-2: devmap already registered
[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][enabled]
 \_ 1:0:0:1 sdb 8:16  [active][ready]
 \_ 2:0:0:1 sdc 8:32  [active][ready]

Parfait non? Il dit [rw] juste là. Pas si vite:

[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system

OK, ne le fait pas automatiquement, je vais juste donner un petit coup de pouce:

[root@localhost ~]# mount -o remount /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

L'enfer que vous êtes:

[root@localhost ~]# mount -o remount,rw /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

Noooooooooo.

J'ai essayé toutes sortes de commandes différentes de mount / tune2fs / dmsetup et je n'arrive pas à comprendre comment l'obtenir pour annuler le marquage du périphérique de bloc comme protégé en écriture. Le redémarrage le corrigera, mais je préfère de loin le faire en ligne. Une heure de recherche sur Google ne m'a mené nulle part non plus. Enregistrez-moi ServerFault.

— cagenut
source

3

hmm, quelques questions 'C'est un problème relativement courant quand quelque chose ne va pas dans un SAN' pourquoi votre SAN est-il si peu fiable, je vérifierais d'abord cela? Avez-vous essayé de démonter avec umount, puis de le remonter? Y a-t-il une bonne raison pour laquelle vous devez effectuer un remontage?. Je n'ai généralement besoin de remonter mes systèmes de fichiers racine qu'après maintenance.

— The Unix Janitor du

umount rebondit sur les descripteurs de fichiers ouverts, qui proviennent souvent de processus que vous préférez de beaucoup quitter en toute sécurité.

— cagenut

J'ai un problème similaire: après un problème de SAN, les disques des machines virtuelles sont en lecture seule et la tentative de remontage provoque la même erreur dans l'OP. Les VM sont sur esxi 4.1 avec un stockage Fibre Channel. Le redémarrage de la VM résout le problème. Personnellement, je ne pense pas que cela ait à voir avec les trajets multiples. Il doit sûrement y avoir un moyen de corriger sans redémarrer, d'autant plus que certains services (apache) ont tendance à continuer à fonctionner sur un FS en lecture seule.

— Le

Je suis venu ici à la recherche d'une solution à mon propre problème (qui est différent, un disque corrompu). J'ai plutôt souri. +1 pour "L'enfer que vous êtes"

— user1207217

J'ai exactement le même problème que celui-ci, mais j'utilise LVM. Le même lvdisplay me donnerait un "échec de lecture après 0 sur 4096 à 449197309952: erreur d'entrée / sortie" jusqu'à ce que je fasse un "multi-trajets -r", puis LVM a commencé à tout afficher correctement sans erreurs. Je ne parviens toujours pas à remonter la partition. Impossible de démonter non plus, indique que l'appareil est occupé. Si j'arrête tous les processus à l'aide de l'appareil, je peux démonter puis remonter avec succès, mais je préférerais simplement pouvoir remonter l'appareil en lecture-écriture, comme je devrais pouvoir ...

— mpontes

6

J'ai récemment rencontré ce problème et l'ai résolu en redémarrant, mais après une enquête plus approfondie, il semble que l'émission de la commande suivante pourrait le résoudre.

echo running > /sys/block/device-name/device/state

Je pense que vous voudrez peut-être regarder la section 25.14.4: Modification de l'état de lecture / écriture d'une unité logique en ligne dans ce document , cependant, je recommande de redémarrer.

— specialKevin
source

Merci Kevin. (Un) heureusement, le problème a disparu depuis longtemps donc je ne peux pas tester mais cela ressemble à l'option la plus prometteuse.

— cagenut

3

Dans un problème similaire, j'ai rencontré que / sys / block / nom-périphérique / périphérique / état était déjà défini sur "en cours d'exécution" et la commande ci-dessus n'a pas résolu le problème.

— Le

3

Essayez d'utiliser:

mount -o remount,rw /mnt/fo

— Desperatuss0ccus
source

Je connais FreeBSD, pas Linux. Mais pour fBSD c'est mount -rw /mnt/foo, donc celui-ci me semble le plus droit.

— Chris S

1

Je n'ai jamais eu ce travail dans le scénario décrit dans la question. Une fois que le disque est marqué en lecture seule en raison d'erreurs, il a toujours pris un redémarrage pour moi.

— Alex

1

Je vais le modifier dans l'OP, mais Alex est ici, le problème semble être en dessous du système de fichiers: [root @ localhost ~] # mount -o remount, rw / mnt / foo mount: block device / dev / mapper / mpath0 est protégé en écriture, montage en lecture seule

— cagenut

1

Avez-vous essayé de démonter la partition et de la remonter? J'ai déjà eu des erreurs de données avec un lecteur, le démontage (ou le remontage, rw) l'a corrigé pour moi. C'était avec les disques SATA (et les anciens EIDE / SCSI) Cependant, dans votre situation, je me demande si le problème est que le canal du disque doit être réinitialisé. Je me demande si HDIO_DRIVE_RESET envoyé via ioctl d'une manière ou d'une autre. blockdev peut être utilisé pour forcer la relecture de la table de partition qui pourrait le faire. IDE expose cela avec hdparm -w, peut-être avec vos lecteurs FC, vous avez un moyen d'envoyer l'ioctl au canal.

2

Je suis un fan d'empêcher le problème en premier lieu. La plupart des boîtes UNIX d'entreprise réessayeront les opérations de système de fichiers comme pour toujours. En tant qu'administrateur, vous devez faire vos devoirs avant de régler votre configuration MPIO. Si votre application doit attendre que l'appareil revienne à un état utilisable, voici une solution. Dans votre /etc/multipath.conf, assurez-vous que le type de périphérique qui vous intéresse possède un paramètre pour "no_path_retry" défini sur "queue". La définition de cette option entraînera la mise en file d'attente des E / S défaillantes jusqu'à ce qu'il existe un chemin valide. Nous avons fait cela pour que nos boîtiers EMC Symmtrix / DMX fonctionnent sur les hoquets dans certaines conditions de panne / récupération de lecteur / contrôleur / chemin srdf.

Cette approche a sauvé notre bacon d'innombrables fois et est notre norme pour des centaines de boîtes sur un SAN multicabinet / multifournisseur avec réplication pour la reprise après sinistre.

Je pensais juste que je pourrais partager avec vous tous. Prends soin de toi.

— TomF
source

2

J'ai eu un problème, que j'ai résolu en utilisant hdparm avec l' -roption sur les sous-lecteurs de périphériques logiques à trajets multiples.

-r Récupère / définit l'indicateur de lecture seule pour le périphérique. Lorsqu'il est défini, Linux interdit les opérations d'écriture sur le périphérique.

— c4f4t0r
source

1

Pensez-vous que cela est lié à la section de ce document intitulée Pourquoi les systèmes de fichiers ext3 sur mon réseau de stockage (SAN) deviennent-ils à plusieurs reprises en lecture seule ?

C'est un article assez ancien, qui parle de Fibre Channel, mais il peut être lié à votre problème.

— Le concierge Unix
source

Oui, ce n'est pas ce bogue spécifique exact puisque j'utilise des versions beaucoup plus récentes que celles auxquelles ils font référence, mais toutes sortes de situations similaires peuvent en être la cause. Le monde de la fibre optique, des pilotes hbas / hba-firmware / hba-drivers, du firmware de la baie, du firmware du commutateur, de la conception de la structure, de la configuration du mappeur de périphériques / multipathd, du lvm et de l'ext3 est tout simplement plein de pièces mobiles. Travaillez sur suffisamment d'environnements et vous verrez ce scénario provoqué par un sac de saisie de problèmes similaires mais pas identiques. La question qui se pose est de savoir comment récupérer / remonter sans redémarrer.

— cagenut

0

Corruption du système de fichiers? Essayer:

dumpe2fs /dev/c/c | grep Filesystem\

En cas de nettoyage avec des erreurs, vous devez numériser et nettoyer.

— codycook
source

-4

Linux ne fait tout simplement pas assez bien face aux SAN de moyenne à grande échelle. Vous DEVEZ y apporter une certaine attention et affiner les délais d'expiration d'E / S et la gestion du délai d'expiration par trajets multiples, ils sont tous à peu près aux valeurs par défaut prêtes pour le bureau.

(Rappelez-vous "rejeter les E / S vers un périphérique mort"?)

— darkfader
source

1

Vous avez vraiment besoin de sauvegarder des déclarations comme «Linux ne résiste pas aux SAN» et «par défaut pour le bureau» avec des références et des faits concrets.

— Chris S

1

Délai d'expiration d'E / S disque par défaut de 30 secondes? Le fil ci-dessus? La note de RedHat (aussi obsolète que cela puisse être) indiquant qu'ils ne peuvent pas gérer une "notification de changement d'état" avec élégance, comme cela serait prévu. Que Redhat par défaut a placé les liaisons multi-trajets dans un emplacement (/ var / lib) qui ne serait pas accessible au moment du chargement du pilote multi-trajets? Que vous ne pouvez pas désactiver à chaud récursivement un hba PCI hotplug et temporairement déconnecter automatiquement tous les LUN dépendants jusqu'à ce qu'il soit remplacé. Qu'il n'a pas d'init HW multithread et prend "un certain temps" pour arriver à> 1k luns. Udev, étant un script shell ...

— darkfader