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


18

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.


3
Hmm, ein paar Fragen: "Es ist ein relativ häufiges Problem, wenn in einem SAN etwas schief geht." Warum ist Ihr SAN so unzuverlässig? Ich würde das zuerst überprüfen. Haben Sie versucht, die Bereitstellung mit umount aufzuheben und dann erneut zu aktivieren? Gibt es einen guten Grund, warum Sie eine erneute Bereitstellung durchführen müssen? Normalerweise muss ich meine Root-Dateisysteme erst nach der Wartung erneut einbinden.
Der Unix-Hausmeister

umount springt auf offene Datei-Handles, die oft von Prozessen stammen, die Sie lieber vernünftig beenden würden.
Cagenut

Ich habe ein ähnliches Problem, bei dem nach einem SAN-Problem VMs-Datenträger schreibgeschützt sind und der Versuch, sie erneut bereitzustellen, denselben Fehler im OP verursacht. VMs sind auf esxi 4.1 mit Fibre Channel-Speicher verfügbar. Ein Neustart der VM behebt das Problem. Ich persönlich denke nicht, dass dies etwas mit Multipath zu tun hat. Sicherlich muss es eine Möglichkeit geben, das Problem ohne Neustart zu beheben, zumal einige Dienste (Apache) in der Regel weiterhin auf einem schreibgeschützten FS ausgeführt werden.
Wird

Ich bin hierher gekommen, um nach einer Lösung für mein eigenes Problem zu suchen (das anders ist, eine beschädigte Festplatte). Ich lächelte stattdessen. +1 für "The hell you are"
user1207217

Ich habe genau das gleiche Problem wie dieses, aber ich verwende LVM. Das gleiche lvdisplay würde mir einen "Fehler beim Lesen nach 0 von 4096 bei 449197309952: Eingabe- / Ausgabefehler" geben, bis ich ein "Multipfad -r" ausführte. Dann begann LVM, alles ohne Fehler richtig anzuzeigen. Ich kann die Partition jedoch immer noch nicht erneut laden. Kann auch nicht abgemeldet werden, sagt Gerät ist beschäftigt. Wenn ich alle Prozesse mit dem Gerät abschalte, kann ich die Bereitstellung aufheben und anschließend erfolgreich wieder aufbauen. Ich würde es jedoch vorziehen, das Gerät nur mit Lese- / Schreibzugriff erneut bereitzustellen, da ich in der Lage sein sollte, ...
mpontes

Antworten:


6

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.


Vielen Dank, Kevin. (Un) zum Glück ist das Problem schon lange nicht mehr vorhanden, daher kann ich es nicht testen, aber dies scheint die vielversprechendste Option zu sein.
Cagenut

3
In einem ähnlichen Problem habe ich festgestellt, dass / sys / block / Gerätename / Gerät / Status bereits auf "Laufen" gesetzt wurde und der obige Befehl das Problem nicht behoben hat.
Wird

3

Versuchen Sie es mit:

mount -o remount,rw /mnt/fo

Ich kenne FreeBSD, nicht Linux. Aber für fBSD ist es das Richtigste mount -rw /mnt/foofür mich.
Chris S

1
Ich habe diese Arbeit in dem in der Frage beschriebenen Szenario noch nie gehabt. Sobald die Festplatte aufgrund von Fehlern als schreibgeschützt markiert ist, wurde für mich immer ein Neustart durchgeführt.
Alex

1
Ich bearbeite dies im OP, aber Alex ist hier richtig, das Problem scheint unter dem Dateisystem zu liegen: [root @ localhost ~] # mount -o remount, rw / mnt / foo mount: Gerät blockieren / dev / mapper mpath0 ist schreibgeschützt und kann nur gelesen werden
cagenut

1
Haben Sie versucht, die Partition zu entfernen und erneut bereitzustellen? Ich hatte zuvor Datenfehler mit einem Laufwerk, das beim Abmelden (oder erneuten Mounten, rw) behoben wurde. Dies war bei SATA-Laufwerken (und älteren EIDE / SCSI-Laufwerken). In Ihrer Situation frage ich mich jedoch, ob das Problem darin besteht, dass der Laufwerkskanal zurückgesetzt werden muss. Ich frage mich, ob HDIO_DRIVE_RESET irgendwie über ioctl gesendet wurde. blockdev kann verwendet werden, um das erneute Lesen der Partitionstabelle zu erzwingen. IDE macht dies mit hdparm -w verfügbar. Vielleicht haben Sie bei Ihren FC-Laufwerken eine Möglichkeit, die ioctl an den Kanal zu senden.

2

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.


2

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.


1

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.


Ja, es ist nicht der exakte spezifische Fehler, da ich viel neuere Versionen als die, auf die sie verweisen, verwende, aber alle möglichen ähnlichen Situationen können ihn verursachen. Die Welt der Fibre-Channel-, Hbas- / Hba-Firmware- / Hba-Treiber-, Array-Firmware-, Switch-Firmware-, Fabric-Design-, Device-Mapper- / Multipathd-Konfiguration-, Lvm- und Ext3-Komponenten besteht nur aus vielen beweglichen Teilen. Wenn Sie in einer ausreichenden Umgebung arbeiten, wird dieses Szenario durch eine Reihe ähnlicher, aber nicht identischer Probleme verursacht. Es stellt sich die Frage, wie das Wiederherstellen / erneutes Bereitstellen ohne Neustart erfolgen kann.
Cagenut

0

Beschädigung des Dateisystems? Versuchen:

dumpe2fs /dev/c/c | grep Filesystem\

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


-4

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"?)


1
Sie müssen wirklich Anweisungen wie "Linux kommt mit SANs nicht zurecht" und "Desktop-Ready-Standardeinstellungen" mit Referenzen und harten Fakten sichern.
Chris S

1
Standardfestplatten-E / A-Zeitüberschreitung von 30 Sekunden? Der obige Thread? Der Hinweis von RedHat (so veraltet es auch sein mag), dass sie eine "Zustandsänderungsmeldung" nicht ordnungsgemäß handhaben können, wie es beabsichtigt wäre. Dass RedHat die Multipath-Bindungen standardmäßig an einem Speicherort (/ var / lib) ablegt, auf den zum Ladezeitpunkt des Multipath-Treibers nicht zugegriffen werden kann? Sie können einen PCI-Hotplug-HBA nicht rekursiv im laufenden Betrieb deaktivieren und alle abhängigen LUNs vorübergehend automatisch offline schalten, bis sie ersetzt wurden. Dass es kein Multithread-HW-Init gibt und es "eine Weile" dauert, bis es> 1k Luns gibt. Udev, ein Shell-Skript ...
Darkfader
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.