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

В настоящее время нет ответа на эту проблему.

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

Пример из dmesg, это симуляция для гостевой Linux на Windows8 с использованием 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 действительно поврежден. Возвратные проблемы с записью зависят от состояния жесткого диска
2. Хост-машина перегружена, тогда записи гостевого виртуального жесткого диска Linux будут синхронизированы
3. Кабель FC или устройство SAN (диски массива по Fibre Channel) перегружены
4. Мгновенное потерянное соединение через FC или FCoE. Возможно потерянный / отсроченный пакет FC

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

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

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

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

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

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

Это некоторые обходные пути, но, как правило, полуприменимы или непригодны:

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

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

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

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

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

(при условии, что sda - ваш диск)

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

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

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

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

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

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

Перезагрузитесь в windows 10, зайдите в настройки питания и отключите быстрое выключение. затем перезагрузите Linux ..gbamm все в порядке.

Быстрое выключение в Windows 10 приводит к гибернации некоторых файлов, и диск используется частично. Linux видит так же занят.