Linux, ¿cómo cambiar el estado del disco duro de ReadOnly después de un bloqueo temporal?


17

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 núcleo decide cambiar la marca de 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 como 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 de los invitados:

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

En mi experiencia esto ocurre en situaciones:

  1. HDD está realmente dañado. Los problemas de escritura devueltos dependen de la condición del HDD
  2. La máquina host está sobrecargada, luego las escrituras de los discos duros virtuales invitados de Linux se registran temporalmente
  3. El cable FC o dispositivo SAN (discos de matriz sobre Fibre Channel) está sobrecargado
  4. Conexión momentánea perdida sobre FC o FCoE. Tal vez el paquete FC perdido / agotado

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 usa como de solo lectura. Esta es la funcionalidad del kernel creada para la prevención de daños, pero solo se puede usar en 1. punto.

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

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

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

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

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

Se trata de algunas soluciones, pero por lo general son semiusables o inutilizables:

  1. Eliminar el módulo admite el acceso al disco duro especificado o al arreglo de almacenamiento. Desafortunadamente, el dispositivo dañado generalmente 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 a esto (fctools), no siempre es posible, no siempre funciona.
  3. Reinicie TODA la máquina. Por lo general, solo 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 lo conectemos nuevamente. Kernel reconoció esto como unirse a un nuevo dispositivo que funciona correctamente. Podemos simular esto usando un dispositivo USB y desconectar momentáneamente la energía. El punto 3. es la última oportunidad y generalmente funciona. ¿Pero por qué deberíamos reiniciar todo? Desafortunadamente, en todos los puntos perdimos todas las actualizaciones de diarios y buffers sucios.

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


No es una respuesta, pero posiblemente esté relacionado en el caso del n. ° 2 (alta carga del host, tiempo de espera del disco duro invitado): aumente el tiempo de espera del disco duro Linux para evitar la corrupción del sistema de archivos causada por los tiempos de espera del disco duro en el sistema invitado.
basic6

@Znik, ¿estas máquinas virtuales invitadas se ejecutan en Citrix XenServer? O hardware físico? Nuestro StorageServer conecta desde la tierra de Ethernet a la tierra de mini-sas. Cuando esta máquina puente entra en pánico, debe reiniciarse con fuerza. Las máquinas virtuales invitadas de Windows vuelven. Las máquinas virtuales invitadas de Linux exhiben el mismo problema exacto que usted tiene. Nada de lo sugerido aquí trae los puntos de montaje de nuevo a rw.
rjt

@rjt, esto ocurre en muchas situaciones. La situación principal es donde el dispositivo se ralentiza extremadamente con cualquier problema, como daño físico, sobrecarga del dispositivo, cableado, FC externo sobre Eth y eth se sobrecarga, a veces se restablece el interruptor cuando se bloquea la transferencia, el tiempo de espera, el paquete perdido, etc. El dispositivo generalmente aún está visible, pero marcado como de solo lectura. El reinicio no es una resolución, es una solución alternativa que describí en la descripción principal de la pregunta / problema.
Znik

Respuestas:


12

probar con blockdev --setrwohdparm -r 0


gracias, esto debería ser útil. Estoy esperando cualquier tiempo de espera en el controlador de
FC

Una parte importante que debe agregarse: a veces es necesario hacer un fscken el sistema de archivos de solo lectura, antes de que pueda montarse nuevamente.
Evi1M4chine

3
No funcionó para mí. tengo un problema similar
jonneymendoza

1
No funcionó para mí incluso con fsck. Invitados de Citrix XenServer Linux.
rjt

No funciona ! Estos comandos parecen efectivos, pero el dongle sigue siendo RO. (es un software, pero ¿¿de dónde ???) Si quieres probar, toma cualquier Debian iso 9.4.
Sandburg

5

Como Jose Luis Martin sugirió usar blockdev, mi 2cent es hacer un remontaje rw y forcefsck

(suponiendo que sda ​​es tu disco)

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

1
Tiene más sentido simplemente ejecutar fsckantes que el mount, ya que no se podrá montar sin él fsck. (Al menos en mi caso lo hizo.)
Evi1M4chine

`# blockdev --setrw / dev / xvda1 # # touch / tmp / date +%Y%m%d-%H%M%Stouch: ¿no se puede tocar? / tmp / 20170722-221904 ?: Sistema de archivos de solo lectura # # mount -o remount, rw / dev / xvda1 [137010.709883] EXT4 -fs error (dispositivo xvda1): ext4_remount: 4824: Aborto forzado por el montaje del usuario: no se puede volver a montar el dispositivo de bloque / dev / xvda1 lectura-escritura, está protegido contra escritura `
rjt

2

Consulte esta página wiki, explica el error que libata arrojó:

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 ser cualquier número de causas. La mayoría de las veces esto se debe a un error del subsistema de interrupción no relacionado (intente arrancar con 'pci = nomsi' o 'acpi = off' o 'noapic'), que no pudo entregar una interrupción cuando esperábamos una del hardware.

Es posible que desee deshabilitar ACPI (verifique cómo hacerlo en función de su distribución) o verifique si su núcleo tiene errores conocidos y posiblemente lo actualice si no es el último (o lo rebaje).


Sí, esto es realmente un tiempo de espera. Por lo general, esto ocurre en el controlador FC cuando el dispositivo de matriz está sobrecargado. Tiene razón, en el subsistema ATA local, esto suele ser cualquier error de hardware o implementación de controlador / chipset
Znik

¿Entonces es un tiempo de espera? Bueno, que sudo hdparm -I /dev/sdX | grep lockeddice? Se debe decir: 'que no esté bloqueado'. Mostraba estos tiempos de espera enigmáticos en el pasado aquí cada vez que un disco duro estaba bloqueado por la contraseña ATA (debido a un borrado de seguridad anterior y un bloqueo del sistema más tarde que provocó que el pw de seguridad no se borrara nuevamente). Estas contraseñas realmente tienen un gran impacto , también en sus nervios. :) Incluso las herramientas estándar enviadas por su proveedor de unidades de HD se comportan como locos, como si la HDD estuviera a punto de morir cuando la contraseña esté activa. El culpable de innumerables mechones de cabello arrancados a lo largo de los años.
syntaxerror

1

Reinicie en Windows 10, vaya a las opciones de energía y apague el apagado rápido. luego reinicie a Linux ... gbamm todo está bien.

el apagado rápido en Windows 10 hiberna algunos archivos y la unidad se usa en parte. así que Linux ve está tan ocupado.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.