Wie kann ein ext3 fs-Readwrite erneut gemountet werden, nachdem er nur aufgrund eines Festplattenfehlers als Readonly gemountet wurde?

Dies ist ein relativ häufiges Problem, wenn in einem SAN für ext3 ein Fehler auftritt, der zum Erkennen von Schreibfehlern auf dem Datenträger und zum erneuten Bereitstellen des schreibgeschützten Dateisystems führt. Das ist alles in Ordnung und gut, nur wenn das SAN repariert ist, kann ich nicht herausfinden, wie das Dateisystem ohne Neustart mit Lese- und Schreibzugriff neu gemountet werden kann.

Erblicken:

[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

Alles gut, jetzt ziehe ich die LUN heraus.

[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

Es denkt nur, dass es schreibgeschützt ist, in Wirklichkeit ist es nicht einmal da.

[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

Wie es sich immer noch daran erinnert, dass diese "Bar" -Datei da ist ... Rätsel, aber momentan nicht wichtig. Jetzt präsentiere ich die 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]

Großartig, oder? Hier steht [rw]. Nicht so schnell:

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

OK, mach das nicht automatisch, ich versuche es einfach mal:

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

Zum Teufel bist du:

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

Noooooooooo.

Ich habe alle möglichen mount / tune2fs / dmsetup-Befehle ausprobiert und kann nicht herausfinden, wie ich das Block-Gerät als schreibgeschützt kennzeichnen kann. Ein Neustart behebt das Problem, aber ich mache es lieber online. Eine Stunde googeln hat mich auch nicht weiter gebracht. Speichern Sie mich ServerFault.

Ich bin vor kurzem auf dieses Problem gestoßen und habe es durch einen Neustart behoben. Nach weiteren Untersuchungen scheint es jedoch so zu sein, dass es durch das Ausgeben des folgenden Befehls behoben werden kann.

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

Vielleicht möchten Sie einen Blick in Abschnitt 25.14.4 werfen: Ändern des Lese- / Schreibzustands einer Online Logical Unit in diesem Dokument . Ich empfehle jedoch einen Neustart.

Versuchen Sie es mit:

mount -o remount,rw /mnt/fo

Ich bin ein Fan davon, das Problem an erster Stelle zu verhindern. Die meisten Enterprise-UNIX-Boxen wiederholen Dateisystemoperationen für immer. Als Administrator müssen Sie einige Hausaufgaben machen, bevor Sie Ihre MPIO-Konfiguration anpassen können. Wenn Ihre Anwendung warten soll, bis das Gerät wieder einsatzbereit ist, finden Sie hier eine Lösung. Stellen Sie in Ihrer Datei /etc/multipath.conf sicher, dass für den gewünschten Gerätetyp die Einstellung "no_path_retry" auf "queue" festgelegt ist. Wenn Sie dies festlegen, werden fehlgeschlagene E / As in die Warteschlange gestellt, bis ein gültiger Pfad vorliegt. Wir haben dies getan, damit unsere EMC Symmtrix / DMX-Boxen unter bestimmten Bedingungen Probleme mit Laufwerks- / Controller- / SDRF-Pfaden / Wiederherstellung beheben können.

Dieser Ansatz hat uns unzählige Male den Speck gerettet und ist unser Standard für Hunderte von Boxen in einem Multicabinet- / Multivendor-SAN mit Replikation für die Notfallwiederherstellung.

Ich dachte nur, ich könnte es mit euch allen teilen. Sich kümmern.

Ich hatte ein Problem, das ich mithilfe von hdparm mit der -rOption auf Sublaufwerken von logischen Multipath-Geräten behoben habe.

-r Nur-Lese-Flag für das Gerät holen / setzen. Wenn gesetzt, erlaubt Linux keine Schreibvorgänge auf dem Gerät.

Denken Sie, dass dies mit dem Abschnitt in diesem Dokument mit dem Titel „ Warum sind die ext3-Dateisysteme in meinem Storage Area Network (SAN) wiederholt schreibgeschützt ?“ Zusammenhängt.

Es ist ein ziemlich alter Artikel, in dem es um Fibre Channel geht, der jedoch möglicherweise mit Ihrem Problem zusammenhängt.

Beschädigung des Dateisystems? Versuchen:

dumpe2fs /dev/c/c | grep Filesystem\

Wenn Sie fehlerfrei sind, müssen Sie scannen und reinigen.

Linux kommt mit mittelgroßen SANs einfach nicht gut genug zurecht. Sie MÜSSEN etwas Sorgfalt walten lassen und die E / A-Zeitüberschreitungen und die Behandlung von Mehrweg-Zeitüberschreitungen optimieren, da sie praktisch alle auf dem Desktop bereit sind.

(Denken Sie daran, "E / A an totes Gerät zurückweisen"?)