Linux, jak zmienić stan dysku twardego z ReadOnly po chwilowej awarii?


17

W tej chwili nie ma odpowiedzi na ten problem.

Zwykle po pewnych problemach z odczytami lub zapisami w celu zablokowania urządzenia, jądro decyduje się na zmianę flagi CAŁEGO URZĄDZENIA jako tylko do odczytu. Następnie wszelkie zapisy na dowolnej partycji / systemie plików znajdującym się na tym urządzeniu powodują przełączenie go jako tylko do odczytu wraz ze stanem urządzenia, ponieważ wszelkie zapisy są niemożliwe.

Przykład z dmesg, to symulacja Linux-a gościa na Windows8 przy użyciu VirtualBox, gdy defrag pobiera obraz urządzenia gościa:

[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.

Następnie zamontuj ponownie przyczynę:

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

ponieważ CAŁE urządzenie sda ​​utrzymujące rootfs sda1 jest DOKŁADNIE.

Z mojego doświadczenia wynika, że ​​dzieje się to w sytuacjach:

  1. Dysk twardy jest naprawdę uszkodzony. Zwrócone problemy z pisaniem zależą od stanu dysku twardego
  2. Komputer hosta jest przeciążony, a następnie limity czasu zapisów wirtualnych dysków twardych gościa linux
  3. Kabel FC lub urządzenie SAN (dyski macierzy przez Fibre Channel) są przeciążone
  4. Chwilowe utrata połączenia przez FC lub FCoE. Może utracony / przekroczony limit czasu pakietu FC

W takich sytuacjach urządzenie jest naprawdę do odczytu i zapisu, ale jądro Linuksa wewnętrznie oznacza to urządzenie jako tylko do odczytu i jest używane jako tylko do odczytu. Jest to funkcja jądra stworzona w celu zapobiegania uszkodzeniom, ale można jej używać tylko w 1. punkcie.

Pytaniem jest. Jak ręcznie powiedzieć kernelowi, że urządzenie blokujące dysk twardy działa normalnie?

Poza tym jądro służy jako urządzenie tylko do odczytu, podobnie jak „CD-ROM”, i żadne inne polecenie nie ma szansy na poprawne działanie, w tym zamontowanie / ponowne zamontowanie -o odczyt-zapis, fsck i inne.

Odpowiedzi bezużyteczne, naprawdę kwalifikowane jako spam od osób, które chcą pomóc, ale nie rozumieją natury problemu:

  1. Spróbuj zamontować ponownie jako odczyt-zapis (niemożliwe, urządzenie ma RO)
  2. fsck to (po co? RO jest urządzeniem, naprawa nie jest możliwa)
  3. „Nie wiem” (najpierw z rozsądkiem, ale bezużyteczne)
  4. „Wymień urządzenie” * (zazwyczaj problemem jest coś innego)

Czy ktoś ma powyższy wzór na pytanie? Czy przełączyć flagę dla zapisywalnego urządzenia blokowego, które przywraca go z trybu tylko do odczytu do stanu do odczytu i zapisu? W tej chwili wydaje się, że nikt nie wie jak.

Jest to kilka obejść, ale zwykle jest to półstabilne lub niezdatne do użytku:

  1. Moduł usuwania obsługuje dostęp do określonego dysku twardego lub macierzy pamięci. Niestety zwykle uszkodzone urządzenie przechowuje rootfs lub sterownik utrzymuje zarówno uszkodzone urządzenie, jak i urządzenie, które utrzymuje rootfs
  2. Usuń dostęp FC do urządzenia i przyłącz się ponownie (fctools), nie zawsze możliwe, nie zawsze działa.
  3. Uruchom ponownie CAŁĄ maszynę. Zwykle tylko to jest zawsze możliwe i zawsze jesteśmy do tego zmuszeni.

W punktach 1. i 2. mówimy kernelowi, że całkowicie odłączamy urządzenie i łączymy się z nim ponownie. Jądro rozpoznało to jako dołączenie do nowego poprawnie działającego urządzenia. Możemy to zasymulować za pomocą urządzenia USB i chwilowo odłączyć zasilanie. Punkt 3. jest ostatnią szansą i zwykle działa. Ale dlaczego wszyscy powinniśmy restartować? Niestety w każdym momencie straciliśmy wszystkie aktualizacje dzienników i brudne bufory.

Zauważ, że w tych samych sytuacjach nie mam problemów z systemem Windows (komputer i serwer).


Brak odpowiedzi, ale możliwe, że związane w przypadku nr 2 (duże obciążenie hosta, limit czasu dysku twardego gościa): Zwiększ limit czasu dysku twardego Linuxa, aby zapobiec uszkodzeniu systemu plików spowodowanego przekroczeniem limitu czasu dysku twardego w systemie gościa.
basic6

@Znik, czy te wirtualne maszyny gościnne działają na Citrix XenServer? Czy fizyczny sprzęt? Nasz StorageServer łączy mosty z krainy Ethernet do krainy mini-sas. Kiedy ta maszyna do mostu wpada w panikę, należy ją ponownie uruchomić. Maszyny wirtualne z systemem Windows wracają. Maszyny wirtualne gościa z systemem Linux wykazują dokładnie taki sam problem, jaki masz. Nic tu sugerowane nie przywraca punktów montowania do rw.
rjt

@rjt, występuje to w wielu sytuacjach. Główna sytuacja ma miejsce, gdy urządzenie jest wyjątkowo spowolnione z jakimkolwiek problemem, takim jak uszkodzenie fizyczne, przeciążenie urządzenia, okablowanie, zewnętrzny FC przez Eth i eth jest przeciążony, czasami reset resetowania po zablokowaniu transferu, przekroczeniu limitu czasu, utracie pakietu itp. Urządzenie zwykle jest nadal widoczne, ale oznaczone jako tylko do odczytu. Ponowne uruchomienie nie oznacza rozwiązania, jest to obejście, jak opisałem w głównym opisie pytania / problemu.
Znik

Odpowiedzi:


12

spróbuj z blockdev --setrwlubhdparm -r 0


dzięki, to powinno się przydać. Czekam na każdą przerwę na kontrolerze
FC

Ważna część, którą należy dodać: Czasami konieczne jest wykonanie w fscksystemie plików tylko do odczytu, zanim będzie można go ponownie zamontować.
Evi1M4chine,

3
Nie działało dla mnie. mam podobny problem
jonneymendoza

1
Nie działało dla mnie nawet z fsck. Goście Citrix XenServer Linux.
rjt

Nie działa ! Te polecenia wydają się skuteczne, ale klucz nadal ma RO. (jest to oprogramowanie, ale skąd?) Jeśli chcesz spróbować, weź dowolną wersję systemu Debian iso 9.4.
Sandburg,

5

Jak Jose Luis Martin sugerował użycie blockdev, moim 2centem jest remount rw i forcefsck

(zakładając, że sda ​​jest twoim dyskiem)

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

1
Bardziej sensowne jest po prostu bieganie fsckprzed nim mount, ponieważ bez niego nie powiedzie się fsck. (Przynajmniej w moim przypadku tak było.)
Evi1M4chine,

`# blockdev --setrw / dev / xvda1 # # touch / tmp / date +%Y%m%d-%H%M%Stouch: can touch? / tmp / 20170722-221904 ?: System plików tylko do odczytu # # mount -o remount, rw / dev / xvda1 [137010.709883] EXT4 -fs błąd (urządzenie xvda1): ext4_remount: 4824: Przerwanie wymuszone przez montowanie przez użytkownika: nie można ponownie zamontować urządzenia blokowego / dev / xvda1 do odczytu i zapisu, jest chroniony przed zapisem `
rjt

2

Sprawdź tę stronę wiki, wyjaśnia błąd zgłoszony przez libata:

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

Z tego, co widzę powyżej, masz problem z przekroczeniem limitu czasu i zgodnie ze wspomnianym dokumentem:

Kontroler nie odpowiedział na aktywne polecenie ATA. Może to być dowolna liczba przyczyn. Najczęściej jest to spowodowane niepowiązanym błędem podsystemu przerwań (spróbuj uruchomić z „pci = nomsi” lub „acpi = off” lub „noapic”), który nie dostarczył przerwania, gdy oczekiwaliśmy od sprzętu.

Możesz wyłączyć ACPI (sprawdź, jak to zrobić w oparciu o swoją dystrybucję) lub sprawdzić jądro pod kątem znanych błędów i ewentualnie zaktualizować je, jeśli nie jest najnowsze (lub obniżyć wersję).


Tak, to naprawdę limit czasu. Zwykle dzieje się tak na kontrolerze FC, gdy urządzenie macierzy jest przeciążone. Masz rację, w lokalnym podsystemie ATA jest to zwykle każdy błąd sprzętowy lub implementacja sterownika / mikroukładu
Znik

Więc to jest przerwa? Co sudo hdparm -I /dev/sdX | grep lockedpowiesz? To musi powiedzieć: „nie zablokowane”. Pokazał te tajemnicze limity czasu w przeszłości tutaj za każdym razem, gdy dysk twardy był blokowany hasłem ATA (z powodu wcześniejszego skasowania bezpieczeństwa i awarii systemu później, co spowodowało, że pw bezpieczeństwa nie został ponownie wyczyszczony). Te hasła mają naprawdę duży wpływ , także na twoje nerwy. :) Nawet standardowe narzędzia dostarczane przez dostawcę twojego dysku HD zachowują się szaleńczo, jakby HDD miał umrzeć, gdy hasło jest aktywne. Sprawcą niezliczonych kępkami włosów wyrwanych przez lata.
składnia błąd

1

Uruchom ponownie w Windows 10, przejdź do opcji zasilania i wyłącz szybkie wyłączanie. następnie uruchom ponownie Linuksa .. gbamm wszystko jest w porządku.

szybkie zamknięcie systemu Windows 10 hibernuje niektóre pliki, a dysk jest częściowo używany. więc Linux widzi, że jest tak zajęty.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.