Linux, как изменить состояние жесткого диска с ReadOnly после временного сбоя?

Question

На данный момент ответа на эту проблему нет.

Обычно после некоторых проблем с чтением или записью на блокируемое устройство ядро ​​решает переключить флаг ВСЕГО УСТРОЙСТВА на «только для чтения». После этого любые записи в любой раздел / файловую систему, расположенную на этом устройстве, вызывают переключение его на «только для чтения» вместе с состоянием устройства, поскольку любые записи невозможны.

Пример из dmesg, это симуляция гостевой ОС Linux на Windows 8 с использованием VirtualBox, когда дефрагментация берет образ гостевого устройства:

[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. HDD действительно поврежден. Возвращенные проблемы записи зависят от состояния HDD
2. Хост-машина перегружена, а затем время записи на виртуальный жесткий диск гостевой ОС Linux истекло
3. Кабель FC или устройство SAN (массив дисков по Fibre Channel) перегружены
4. Кратковременная потеря соединения через FC или FCoE. Возможно, потерян/истек тайм-аут пакета FC

В этой ситуации устройство действительно доступно для чтения и записи, но ядро ​​Linux помечает это устройство как доступное только для чтения и используется как доступное только для чтения. Это функционал ядра, созданный для предотвращения повреждений, но он применим только в точке 1.

Вопрос в следующем. Как вручную сообщить ядру, что блочное устройство hdd работает нормально?

Без этого ядро ​​обслуживает устройство только для чтения, как «CD-ROM», и никакая другая команда не сможет работать правильно, включая mount/remount -o read-write, fsck и другие.

Бесполезные ответы, которые на самом деле расцениваются как спам от людей, которые хотят помочь, но не понимают сути проблемы:

1. Попробуйте перемонтировать в режиме чтения-записи (невозможно, устройство RO)
2. fsck это (зачем? устройство RO, ремонт невозможен)
3. «Я не знаю» (первое осмысленное, но бесполезное)
4. «Замените устройство» *(обычно проблема в чем-то другом)

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

Существуют некоторые обходные пути, но обычно они полупригодны или бесполезны:

1. Модуль Remove поддерживает доступ к указанному жесткому диску или массиву хранения. К сожалению, обычно поврежденное устройство сохраняет rootfs, или драйвер сохраняет как поврежденное устройство, так и устройство, которое сохраняет rootfs
2. Удалить доступ FC к устройству и подключить его снова (fctools) не всегда возможно и не всегда работает.
3. Перезагрузите ВСЮ машину. Обычно только это всегда возможно, и мы всегда вынуждены это делать.

В пунктах 1 и 2 мы говорим ядру, что мы полностью отключаем устройство и подключаемся к нему снова. Ядро распознает это как присоединение нового правильно работающего устройства. Мы можем смоделировать это с помощью USB-устройства и кратковременного отключения питания. Пункт 3 — это последний шанс, и он обычно работает. Но почему мы должны перезапускать все? К сожалению, во всех пунктах мы потеряли все обновления журналов и грязные буферы.

Обратите внимание, в тех же ситуациях у меня нет проблем с Windows (на десктопе и сервере).

Answer 1

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

Answer 2

Как и предложил Хосе Луис Мартин, использовать blockdev, мой совет — сделать перемонтирование rw и forcefsck

(предполагается, что sda — это ваш диск)

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

Answer 3

Проверьте эту страницу вики, там объясняется ошибка, выдаваемая libata:

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

Из того, что я вижу выше, у вас возникла проблема с тайм-аутом, и согласно упомянутому документу:

Контроллер не ответил на активную команду ATA. Это может быть вызвано множеством причин. Чаще всего это происходит из-за несвязанной ошибки подсистемы прерываний (попробуйте загрузиться с 'pci=nomsi' или 'acpi=off' или 'noapic'), которая не смогла предоставить прерывание, когда мы ожидали его от оборудования.

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

Answer 4

###Привет, следующие команды могут помочь. Однако небезопасно отмонтировать или пытаться изменить корневую файловую систему работающего диска. Вместо этого загрузите систему с загрузочного устройства.

1. Найдите диск в системе.

$ mount | grep /dev/

2. Размонтировать диск

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

3. Проверьте и восстановите файловую систему с помощью любой из следующих команд

###для устройства ext4

$ sudo fsck.ext4 -f /dev/sda1

###для устройства DOS

$ sudo dosfsck -a /dev/sda1

###или вы можете просто выполнить fsckкоманду.

$ sudo fsck /dev/sda1

4. Перемонтируйте устройство.

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

Это создаст новую точку монтирования. Затем выполните:

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

Вы готовы. Однако, для получения более подробной информации о командах вы можете ознакомиться сBaeldung