Comment remonter une lecture / écriture ext3 fs après l'avoir montée en lecture seule à partir d'une erreur de disque?
C'est un problème relativement courant quand quelque chose se passe mal 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 corrigé, je ne peux pas comprendre comment remonter 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 l'instant. 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 lui 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 le faire 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. Sauvez-moi ServerFault.
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 regardez la section 25.14.4: Changer l'état de lecture/écriture d'une unité logique en ligne dans ce document , cependant, je recommande de redémarrer.
Essayez d'utiliser:
mount -o remount,rw /mnt/fo
J'ai eu un problème, que j'ai résolu en utilisant hdparm avec le -r option sur les sous-lecteurs de périphériques logiques à chemins 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.
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, alors 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 l'avons fait pour que nos boîtiers EMC Symmtrix/DMX fonctionnent sur le hoquet dans certaines conditions de panne/récupération de lecteur/contrôleur/chemin srdf. Lorsque vous souhaitez faire échouer le périphérique manuellement pendant une défaillance, cela devient plus compliqué car vous devrez utiliser des outils tels que dmsetup pour vider/échouer les E/S ou modifier temporairement le fichier multipath.conf et réanalyser les périphériques .... etc.
Cette approche a sauvé notre bacon d'innombrables fois et est notre norme pour des centaines de boîtes sur un multicabinet/multivendor SAN avec réplication pour la reprise après sinistre).
Je pensais juste que je pourrais partager avec vous tous. Prends soin de toi.
Pensez-vous que cela soit 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.
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.