Linux, ¿cómo cambiar el estado del disco duro de Solo lectura después de un fallo temporal?

Question

En este momento no hay respuesta para este problema.

Por lo general, después de algunos problemas con las lecturas o escrituras para bloquear el dispositivo, el kernel decide cambiar el indicador para TODO EL DISPOSITIVO como de solo lectura. Después de esto, cualquier escritura en cualquier partición/sistema de archivos ubicado en este dispositivo hace que se cambie a solo lectura junto con el estado del dispositivo, porque cualquier escritura es imposible.

Ejemplo de dmesg, esta es una simulación para Linux invitado en Windows8 usando VirtualBox cuando la desfragmentación toma la imagen del dispositivo invitado:

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

Después de esto, vuelva a montar la causa:

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

porque TODO el dispositivo sda que mantiene rootfs sda1 es SÓLO LECTURA.

En mi experiencia, esto ocurre en situaciones:

1. El disco duro está realmente dañado. Los problemas de escritura devueltos dependen del estado del HDD
2. La máquina host está sobrecargada, luego se agota el tiempo de espera para las escrituras del disco duro virtual invitado de Linux
3. El cable FC o el dispositivo SAN (discos de matriz a través de Fibre Channel) están sobrecargados
4. Conexión perdida momentáneamente a través de FC o FCoE. Quizás el paquete FC se perdió o se agotó el tiempo de espera

En estas situaciones, el dispositivo es realmente de lectura y escritura, pero el kernel de Linux marca este dispositivo internamente como de solo lectura y se utiliza como de solo lectura. Esta es una funcionalidad del kernel creada para la prevención de daños, pero solo se puede utilizar en un punto.

La pregunta es. ¿Cómo decirle manualmente al kernel que el dispositivo de bloqueo del disco duro funciona normalmente?

Sin esto, el kernel sirve al dispositivo como de solo lectura, como 'CD-ROM', y ningún otro comando tiene la posibilidad de funcionar correctamente, incluido mount/remount -o read-write, fsck y otros.

Respuestas inutilizables, realmente calificadas como spam de personas que quieren ayudar, pero no entienden la naturaleza del problema:

1. Intente volver a montar como lectura-escritura (imposible, el dispositivo es RO)
2. fsck esto (¿para qué? el dispositivo es RO, no es posible repararlo)
3. 'No lo sé' (primero con sentido, pero inutilizable)
4. 'Reemplaza tu dispositivo' *(normalmente el problema es otro)

¿Alguien tiene alguna fórmula para la pregunta anterior? ¿Cambiar indicador para dispositivo de bloque grabable que lo revierte del estado de solo lectura al estado de lectura-escritura? En este momento parece que nadie sabe cómo.

Se trata de algunas soluciones, pero generalmente semiutilizables o inutilizables:

1. Quitar módulo admite el acceso al disco duro o matriz de almacenamiento especificados. Desafortunadamente, generalmente el dispositivo dañado mantiene rootfs, o el controlador mantiene tanto el dispositivo dañado como el dispositivo que mantiene rootfs.
2. Elimine el acceso FC al dispositivo y vuelva a unirse (fctools), no siempre es posible, no siempre funciona.
3. Reinicie TODA la máquina. Normalmente sólo esto es siempre posible y siempre estamos obligados a hacerlo.

En los puntos 1. y 2. le decimos al kernel que desconectemos completamente el dispositivo y nos conectemos nuevamente. Kernel reconoció que esto se unía a un nuevo dispositivo que funcionaba correctamente. Podemos simular esto usando un dispositivo USB y desconectar momentáneamente la energía. El punto 3. es la última oportunidad y normalmente funciona. Pero ¿por qué deberíamos reiniciar todo? Lamentablemente, en todos los puntos perdimos todas las actualizaciones de los diarios y los buffers sucios.

Aviso, en las mismas situaciones no tengo problemas con Windows (escritorio y servidor).

Answer 1

prueba con blockdev --setrwohdparm -r 0

Answer 2

Como José Luis Martín sugirió usar blockdev, mi 2cent es hacer un remontaje de rw y forcefsck.

(suponiendo que sda ​​sea su disco)

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

Answer 3

Consulte esta página wiki, explica el error arrojado por libata:

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

Por lo que veo arriba, tienes un problema de tiempo de espera y según el documento mencionado:

El controlador no pudo responder a un comando ATA activo. Esto podría deberse a varias causas. En la mayoría de los casos, esto se debe a un error del subsistema de interrupciones no relacionado (intente arrancar con 'pci=nomsi' o 'acpi=off' o 'noapic'), que no logró generar una interrupción cuando esperábamos una del hardware.

Es posible que desee deshabilitar ACPI (consulte cómo hacerlo según su distribución) o verificar su kernel en busca de errores conocidos y posiblemente actualizarlo si no es el más reciente (o degradarlo).

Answer 4

###Hola, los siguientes comandos pueden ayudar. Sin embargo, no es seguro desmontar o intentar modificar el sistema de archivos raíz de una unidad en ejecución. En su lugar, inicie el sistema desde un dispositivo de inicio.

1. Localice la unidad en el sistema

$ mount | grep /dev/

2. Desmontar la unidad

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

3. Verifique y repare el sistema de archivos con cualquiera de los siguientes comandos

###para un dispositivo ext4

$ sudo fsck.ext4 -f /dev/sda1

###para un dispositivo DOS

$ sudo dosfsck -a /dev/sda1

###o simplemente puede ejecutar el fsckcomando.

$ sudo fsck /dev/sda1

4. Vuelva a montar el dispositivo

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

Esto creará un nuevo punto de montaje. Entonces corre:

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

Eres bueno para ir. Sin embargo, para obtener más detalles sobre los comandos, puede consultarBaeldung