Linux, wie ändert man den HDD-Status nach einem vorübergehenden Absturz von „ReadOnly“?

Question

Derzeit keine Antwort auf dieses Problem.

Normalerweise entscheidet der Kernel nach einigen Problemen mit Lese- oder Schreibvorgängen auf blockierten Geräten, das Flag für das GESAMTE GERÄT auf schreibgeschützt zu setzen. Danach führt jeder Schreibvorgang auf eine Partition/ein Dateisystem auf diesem Gerät dazu, dass es zusammen mit dem Gerätestatus auf schreibgeschützt gesetzt wird, da jeglicher Schreibvorgang unmöglich ist.

Beispiel von dmesg, dies ist eine Simulation für einen Linux-Gast unter Windows 8 unter Verwendung von VirtualBox, wenn bei der Defragmentierung ein Geräteabbild des Gastes erstellt wird:

[11903.002030] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11903.003179] ata3.00: failed command: READ FPDMA QUEUED
[11903.003364] ata3.00: cmd 60/08:00:a8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11903.003385]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11903.004074] ata3.00: status: { DRDY }
[11903.004248] ata3: hard resetting link
[11903.325703] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11903.327097] ata3.00: configured for UDMA/133
[11903.328025] ata3.00: device reported invalid CHS sector 0
[11903.329664] ata3: EH complete
[11941.000472] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11941.000769] ata3.00: failed command: READ FPDMA QUEUED
[11941.000952] ata3.00: cmd 60/08:00:c8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11941.000961]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11941.001353] ata3.00: status: { DRDY }
[11941.001504] ata3: hard resetting link
[11941.320297] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11941.321252] ata3.00: configured for UDMA/133
[11941.321379] ata3.00: device reported invalid CHS sector 0
[11941.321553] ata3: EH complete
[11980.001746] ata3.00: exception Emask 0x0 SAct 0x11fff SErr 0x0 action 0x6 frozen
[11980.002070] ata3.00: failed command: WRITE FPDMA QUEUED
[11980.002255] ata3.00: cmd 61/18:00:28:23:59/00:00:00:00:00/40 tag 0 ncq 12288 out
[11980.002265]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
-------------------
There are many other errors, like "lost write page", "Journal has aborted", "Buffer I/O error", "hard resetting link" and many others.

Danach Ursache erneut mounten:

mount / -o remount,rw
mount: cannot remount block device /dev/sda1 read-write, is write-protected

weil das GESAMTE Gerät-SDA, das Rootfs sda1 behält, NUR-LESEN kann.

Meiner Erfahrung nach tritt dies in folgenden Situationen auf:

1. Die Festplatte ist wirklich beschädigt. Wiederkehrende Schreibprobleme hängen vom Zustand der Festplatte ab
2. Der Hostcomputer ist überlastet, dann kommt es beim Schreiben virtueller Festplatten des Linux-Gasts zu einer Zeitüberschreitung
3. FC-Kabel oder SAN-Gerät (Array-Festplatten über Fibre Channel) ist überlastet
4. Verbindung über FC oder FCoE kurzzeitig verloren. Möglicherweise verlorenes/überschrittenes FC-Paket

In dieser Situation ist das Gerät eigentlich schreibgeschützt, aber der Linux-Kernel markiert dieses Gerät intern als schreibgeschützt und wird als schreibgeschützt verwendet. Dies ist eine Kernelfunktionalität zur Schadensverhütung, die jedoch nur an einem Punkt verwendet werden kann.

Die Frage ist: Wie kann ich dem Kernel manuell mitteilen, dass das HDD-Blockgerät normal funktioniert?

Ohne diese Funktion dient der Kernel dem Gerät als schreibgeschützt, z. B. „CD-ROM“, und kein anderer Befehl funktioniert ordnungsgemäß, einschließlich „mount/remount -o read-write“, „fsck“ und anderen.

Unbrauchbare Antworten, eigentlich Spam, von Leuten, die helfen wollen, aber die Natur des Problems nicht verstehen:

1. Versuchen Sie, die Bereitstellung mit Lese-/Schreibzugriff erneut durchzuführen (unmöglich, das Gerät ist RO).
2. fsck dies (wofür? Gerät ist RO, keine Reparatur möglich)
3. „Ich weiß nicht“ (zuerst sinnvoll, aber unbrauchbar)
4. „Ersetzen Sie Ihr Gerät“ *(normalerweise liegt das Problem woanders)

Hat jemand eine Formel für die obige Frage? Schalterflag für beschreibbares Blockgerät, das es vom schreibgeschützten in den Lese-/Schreibzustand zurücksetzt? Im Moment scheint niemand zu wissen, wie das geht.

Es gibt einige Workarounds, die aber normalerweise nur bedingt oder gar nicht verwendbar sind:

1. Das Modul „Entfernen“ unterstützt den Zugriff auf die angegebene Festplatte oder das angegebene Speicherarray. Leider behält das beschädigte Gerät normalerweise das Root-FS, oder der Treiber behält sowohl das beschädigte Gerät als auch das Gerät, das das Root-FS behält.
2. FC-Zugriff auf Gerät entfernen und erneut verbinden (fctools), nicht immer möglich, funktioniert nicht immer.
3. Starten Sie die GANZE Maschine neu. Normalerweise ist nur dies immer möglich und wir sind immer dazu gezwungen.

Bei Punkt 1 und 2 sagen wir dem Kernel, dass wir das Gerät komplett trennen und erneut verbinden. Der Kernel erkennt dies als Verbindung zu einem neuen, ordnungsgemäß funktionierenden Gerät. Wir können dies mit einem USB-Gerät simulieren und die Stromversorgung kurzzeitig unterbrechen. Punkt 3 ist die letzte Möglichkeit und funktioniert normalerweise. Aber warum sollten wir alles neu starten? Leider haben wir bei allen Punkten alle Journal-Updates und schmutzigen Puffer verloren.

Beachten Sie, dass ich in den gleichen Situationen keine Probleme mit Windows (Desktop und Server) habe.

Answer 1

versuchen Sie es mit blockdev --setrwoderhdparm -r 0

Answer 2

Wie Jose Luis Martin vorgeschlagen hat, verwenden Sie Blockdev. Meine 2 Cent sind, ein Remount RW und Forcefsck durchzuführen.

(vorausgesetzt, sda ist Ihre Festplatte)

blockdev --setrw /dev/sda
mount /dev/sda -o remount,rw
touch /forcefsck

Answer 3

Schauen Sie sich diese Wiki-Seite an, dort wird der von libata ausgegebene Fehler erklärt:

https://ata.wiki.kernel.org/index.php/Libata_error_messages

Soweit ich das oben sehe, liegt ein Timeout-Problem vor. Gemäß dem genannten Dokument gilt:

Der Controller konnte nicht auf einen aktiven ATA-Befehl reagieren. Dies kann verschiedene Ursachen haben. Am häufigsten liegt dies an einem unabhängigen Fehler im Interrupt-Subsystem (versuchen Sie, mit „pci=nomsi“ oder „acpi=off“ oder „noapic“ zu booten), das keinen Interrupt lieferte, obwohl wir einen von der Hardware erwarteten.

Möglicherweise möchten Sie ACPI deaktivieren (prüfen Sie, wie das bei Ihrer Distribution geht) oder Ihren Kernel auf bekannte Fehler überprüfen und ihn ggf. aktualisieren, wenn er nicht der neueste ist (oder ein Downgrade durchführen).

Answer 4

###Hallo, die folgenden Befehle können helfen. Es ist jedoch nicht sicher, ein laufendes Laufwerk auszuhängen oder zu versuchen, das Root-Dateisystem zu ändern. Booten Sie das System stattdessen von einem bootfähigen Gerät.

1. Suchen Sie das Laufwerk im System

$ mount | grep /dev/

2. Unmounten des Laufwerks

$ sudo umount <your-mount-point-name>

3. Überprüfen und reparieren Sie das Dateisystem mit einem der folgenden Befehle

###für ein ext4-Gerät

$ sudo fsck.ext4 -f /dev/sda1

###für ein DOS-Gerät

$ sudo dosfsck -a /dev/sda1

###oder Sie können einfach den fsckBefehl ausführen.

$ sudo fsck /dev/sda1

4. Montieren Sie das Gerät erneut

$ sudo mkdir <your-mount-point-name>

Dadurch wird ein neuer Einhängepunkt erstellt. Führen Sie dann Folgendes aus:

$ sudo mount -o rw,uid=1000,gid=1000,user,exec,umask=003,blksize=4096 /dev/sdc1 /media/<your-mount-point-name>

Sie können loslegen. Weitere Einzelheiten zu den Befehlen finden Sie unterBaeldung