Linux, як змінити стан жорсткого диска з ReadOnly після тимчасової аварії?


17

Наразі немає жодної відповіді на цю проблему.

Зазвичай після деяких проблем із читаннями чи записами для блокування пристрою, ядро ​​вирішує переключити прапор НА ЦІЛЬНУ ПРИСТРОЮ як лише для читання. Після цього будь-які записи в будь-який розділ / файлову систему, що знаходиться на цьому пристрої, викликають перемикання його як повністю прочитане разом із станом пристрою, оскільки будь-які записи неможливі.

Приклад з dmesg, це моделювання для гостьового Linux на Windows8 за допомогою VirtualBox, коли defrag знімає зображення пристрою гостей:

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

Після цього перераховуйте причину:

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

тому що КОЛИЙ пристрій sda, що зберігає rootfs sda1, НАЙКРАДНО.

На мій досвід, це відбувається в таких ситуаціях:

  1. Жорсткий диск дійсно пошкоджений. Повернені проблеми із записом залежать від стану жорсткого диска
  2. Хост-машина перевантажена, тоді записи віртуального жорсткого жорсткого диска linux затягуються
  3. Кабель FC або SAN-пристрій (диски масиву по Fiber Channel) перевантажені
  4. Моментне втрачене з'єднання через FC або FCoE. Можливо, загублений / вичерпаний пакет FC

У цій ситуації пристрій дійсно читає-пише, але ядро ​​Linux позначає цей пристрій внутрішньо як лише для читання і використовується як лише для читання. Це функціональність ядра, створена для запобігання пошкодженням, але вона може використовуватися лише в 1. точці.

Питання є. Як вручну сказати ядро, що пристрій блокування hdd працює нормально?

Якщо це буде, ядро ​​служить пристрою лише для читання, як-от "CD-ROM", і жодна інша команда не має шансів працювати належним чином, включаючи mount / remount -o read-write, fsck та інші.

Непридатні відповіді, справді кваліфіковані як спам від людей, які хочуть допомогти, але не розуміють про проблему:

  1. Спробуйте перезаписати як читання-запис (неможливо, пристрій - RO)
  2. fsck це (що для? пристрою RO, ремонт не можливий)
  3. "Я не знаю" (спочатку з розумом, але непридатним)
  4. "Замініть свій пристрій" * (зазвичай проблема полягає в чомусь іншому)

Хтось має формулу для питання вище? Переключити прапор блокового пристрою, що записується, який повертає його з режиму лише для читання до стану читання-запису? У цей час здається, що ніхто не знає як.

Це деякі способи вирішення, але зазвичай напівпридатні або непридатні для використання:

  1. Видалити модуль підтримує доступ до вказаного hdd або масиву зберігання. На жаль, зазвичай пошкоджений пристрій зберігає рутви, або драйвер зберігає як пошкоджений пристрій, так і пристрій, який зберігає rootfs
  2. Видаліть доступ FC до пристрою і приєднайтеся до цього знову (fctools), не завжди це можливо, не завжди працює.
  3. Перезавантажте всю машину. Зазвичай тільки це завжди можливо, і ми завжди змушені це робити.

У пунктах 1. і 2. ми кажемо ядру, що ми повністю відключаємо пристрій і знову підключаємось до нього. Кернел визнав це приєднанням до нового належного операційного пристрою. Ми можемо імітувати це за допомогою USB-пристрою та миттєвого відключення живлення. Точка 3. є останнім шансом і зазвичай працює. Але чому ми повинні все перезапустити? На жаль, у всіх моментах ми втратили всі оновлення журналів та брудні буфери.

Зауважте, в тих же ситуаціях у мене немає проблем із Windows (настільний ПК та сервер).


Не відповідь, але можливо пов’язана у випадку №2 (велика завантаженість хоста, час очікування hdd гості): збільшити час очікування hdd Linux для запобігання пошкодження файлової системи, спричиненого таймаутами hdd в гостьовій системі.
basic6

@ Znik, ці гостьові віртуальні машини працюють на Citrix XenServer? Або фізичне обладнання? Наш StorageServer мости від землі Ethernet до землі mini-sas. Коли ця мостова машина панікує, її потрібно насильно перезавантажити. VM-гості Windows повертаються. Гості віртуальних машин Linux мають таку саму точну проблему, що і у вас. Ніщо, що пропонується тут, не повертає точки кріплення до rw.
rjt

@rjt, це трапляється у багатьох ситуаціях. Основна ситуація, коли пристрій надзвичайно сповільнюється з будь-якою проблемою, як-от фізичне пошкодження, перевантаження пристрою, підключення кабелів, зовнішнє перевантаження FC над Eth і eth перевантажено, іноді скидання перемикання при блоці передачі, тайм-аут, втрачений пакет тощо. Пристрій все ще видно, але позначені як лише прочитані. Перезавантаження не є роздільною здатністю, це рішення, як я описав у головному описі / описі проблеми.
Znik

Відповіді:


12

спробуйте blockdev --setrwабоhdparm -r 0


дякую, це має бути корисним. Я чекаю будь-якого тайм-ауту на контролері fc
Znik

Важлива частина, яку потрібно додати: Іноді доводиться робити fsckфайлову систему лише для читання, перш ніж її можна буде знову встановити.
Evi1M4chine

3
Дідднт працює для мене. У мене є подібна проблема
jonneymendoza

1
Не працював для мене навіть з fsck. Гості Citrix XenServer Linux.
rjt

Не працює ! Ці команди здаються ефективними, але ключ все ще є RO. (це програмне забезпечення, але звідки ???) Якщо ви хочете спробувати, візьміть будь-який Debian iso 9.4.
Сандбург

5

Як Жозе Луїс Мартін запропонував використовувати blockdev, мій 2cent - це зробити перезавантаження rw і forcefsck

(припустимо, що sda - це ваш диск)

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

1
Більше сенсу просто запустити fsckперед тим mount, як він не зможе встановитись без fsck. (Принаймні, в моєму випадку так і було.)
Evi1M4chine

`# # blockdev --setrw / dev / xvda1 # # touch / tmp / date +%Y%m%d-%H%M%Stouch: не можна торкатися? / tmp / 20170722-221904 ?: файлова система лише для читання # # mount -o remount, rw / dev / xvda1 [137010.709883] EXT4 -fs помилка (пристрій xvda1): ext4_remount: 4824: Скасувати змушене користувачем кріплення: не вдається перезавантажити блок пристрою / dev / xvda1 для читання-запису, захищений від запису `
rjt

2

Перевірте цю вікі-сторінку, вона пояснює помилку, яку видав libata:

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

З того, що я бачу вище, у вас з’явився випуск часу та відповідно до згаданого документа:

Контролер не зміг відповісти на активну команду ATA. Це може бути будь-яка кількість причин. Найчастіше це пов’язано з непов'язаною помилкою підсистеми переривання (спробуйте завантажуватися з 'pci = nomsi' або 'acpi = off' або 'noapic'), яка не змогла доставити переривання, коли ми очікували його на апаратному забезпеченні.

Ви можете відключити ACPI (перевірте, як базуватись на вашому дистрибутиві) або перевірити ядро ​​на наявність відомих помилок і, можливо, оновити його, якщо він не є останнім (або понизити його).


Так, це справді таймаут. Зазвичай це відбувається на контролері FC, коли пристрій масиву перевантажений. Ви маєте рацію, в локальній підсистемі ATA це звичайно будь-яка апаратна помилка або реалізація драйвера / чіпсета
Znik

Так це таймаут? Ну, що sudo hdparm -I /dev/sdX | grep lockedговорить? Він повинен сказати: "не заблокований". Він показав ці загадкові тайм-аути в минулому тут кожного разу, коли жорсткий диск був заблокований паролем ATA (через попереднє стирання безпеки та згортання системи згодом, що призвело до того, що не вдалося знову очистити файл безпеки). Цей матеріал із паролем дійсно має величезний вплив також на ваші нерви. :) Навіть стандартні інструменти, що постачаються вашим постачальником HD-дисків, ведуть себе шалено, начебто жорсткий диск ось-ось помре, коли пароль активований. Винуватцем незліченних пучків волосся , вирваних через роки.
синтаксис-помилка

1

Перезавантажте Windows 10, перейдіть до параметрів живлення та вимкніть швидке відключення. потім перезавантажте Linux ... gbamm все добре.

швидке відключення у Windows 10 впадає в режим зимування деяких файлів, а привід частково використовується. тому Linux бачить настільки ж зайнятий.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.