¿Cómo se vuelve a montar un ext3 fs readwrite después de que se monta solo lectura de un error de disco?

18

Es un problema relativamente común cuando algo sale mal en una SAN para que ext3 detecte los errores de escritura del disco y vuelva a montar el sistema de archivos de solo lectura. Eso está muy bien, solo cuando la SAN está reparada no puedo entender cómo volver a montar el sistema de archivos de lectura-escritura sin reiniciar.

Mirad: 

[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:1 sdb 8:16  [active][ready]
\_ 2:0:0:1 sdc 8:32  [active][ready]
[root@localhost ~]# mount /dev/mapper/mpath0 /mnt/foo
[root@localhost ~]# touch /mnt/foo/blah

Todo bien, ahora saco el LUN de debajo.

[root@localhost ~]# touch /mnt/foo/blah
[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system
[root@localhost ~]# tail /var/log/messages
Mar 18 13:17:33 localhost multipathd: sdb: tur checker reports path is down
Mar 18 13:17:34 localhost multipathd: sdc: tur checker reports path is down
Mar 18 13:17:35 localhost kernel: Aborting journal on device dm-2.
Mar 18 13:17:35 localhost kernel: Buffer I/O error on device dm-2, logical block 1545
Mar 18 13:17:35 localhost kernel: lost page write due to I/O error on dm-2
Mar 18 13:17:36 localhost kernel: ext3_abort called.
Mar 18 13:17:36 localhost kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb:   Detected aborted journal                      
Mar 18 13:17:36 localhost kernel: Remounting filesystem read-only

Solo piensa que es de solo lectura, en realidad ni siquiera está allí.

[root@localhost ~]# multipath -ll
sdb: checker msg is "tur checker reports path is down"
sdc: checker msg is "tur checker reports path is down"
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=0][hwhandler=0][rw]
\_ round-robin 0 [prio=0][enabled]
 \_ 1:0:0:1 sdb 8:16  [failed][faulty]
 \_ 2:0:0:1 sdc 8:32  [failed][faulty]
[root@localhost ~]# ll /mnt/foo/
ls: reading directory /mnt/foo/: Input/output error
total 20
-rw-r--r-- 1 root root     0 Mar 18 13:11 bar

Cómo todavía recuerda que ese archivo 'bar' está allí ... misterio, pero no importante en este momento. Ahora vuelvo a presentar el LUN:

[root@localhost ~]# tail /var/log/messages
Mar 18 13:23:58 localhost multipathd: sdb: tur checker reports path is up
Mar 18 13:23:58 localhost multipathd: 8:16: reinstated
Mar 18 13:23:58 localhost multipathd: mpath0: queue_if_no_path enabled
Mar 18 13:23:58 localhost multipathd: mpath0: Recovered to normal mode
Mar 18 13:23:58 localhost multipathd: mpath0: remaining active paths: 1
Mar 18 13:23:58 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:58 localhost multipathd: dm-2: devmap already registered
Mar 18 13:23:59 localhost multipathd: sdc: tur checker reports path is up
Mar 18 13:23:59 localhost multipathd: 8:32: reinstated
Mar 18 13:23:59 localhost multipathd: mpath0: remaining active paths: 2
Mar 18 13:23:59 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:59 localhost multipathd: dm-2: devmap already registered
[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][enabled]
 \_ 1:0:0:1 sdb 8:16  [active][ready]
 \_ 2:0:0:1 sdc 8:32  [active][ready]

Genial verdad? Dice [rw] allí mismo. No tan rapido:

[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system

OK, no lo hace automáticamente, solo daré un pequeño empujón:

[root@localhost ~]# mount -o remount /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

Que diablos eres:

[root@localhost ~]# mount -o remount,rw /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

Noooooooooo

He intentado todo tipo de diferentes comandos mount / tune2fs / dmsetup y no puedo encontrar la manera de hacer que no marque el dispositivo de bloque como protegido contra escritura. El reinicio lo arreglará, pero preferiría hacerlo en línea. Una hora de búsqueda en Google no me ha llevado a ninguna parte tampoco. Sálvame ServerFault.

centos mount ext3 read-only cagenut
fuente
3
hmm, un par de preguntas "Es un problema relativamente común cuando algo sale mal en una SAN" ¿ por qué su SAN no es tan confiable? ¿Lo comprobaría primero? ¿Has intentado desmontar con umount y luego volver a montarlo? ¿Hay una buena razón por la que necesita hacer un montaje? Por lo general, solo necesito volver a montar mis sistemas de archivos raíz después del mantenimiento.
The Unix Janitor
umount rebota en los identificadores de archivos abiertos, que a menudo provienen de procesos que preferiría que salga de manera sensata.
cagenut
Tengo un problema similar en el que, después de un problema de SAN, los discos de las máquinas virtuales son de solo lectura y el intento de volver a montar causa el mismo error en el OP. Las máquinas virtuales están en esxi 4.1 con almacenamiento de canal de fibra. El reinicio de VM soluciona el problema. Personalmente, no creo que esto tenga nada que ver con la trayectoria múltiple. Seguramente debe haber una manera de solucionarlo sin reiniciar, especialmente porque algunos servicios (apache) tienden a seguir ejecutándose en un FS de solo lectura.
Se
Vine aquí buscando una solución a mi propio problema (que es diferente, un disco dañado). Sonreí en su lugar. +1 para "El infierno que eres"
user1207217
Tengo exactamente el mismo problema que este, pero estoy usando LVM. La misma pantalla lv me daría un "error de lectura después de 0 de 4096 en 449197309952: error de entrada / salida" hasta que hice un "multirruta -r", luego LVM comenzó a mostrar todo correctamente sin errores. Sin embargo, todavía no puedo volver a montar la partición. No se puede desmontar tampoco, dice que el dispositivo está ocupado. Si apago todos los procesos que usan el dispositivo, puedo desmontar y luego volver a montar con éxito, pero preferiría poder volver a montar el dispositivo de lectura y escritura, ya que debería poder ...
mpontes

Respuestas:

6

Recientemente me encontré con este problema y lo resolví reiniciando, pero después de una investigación más profunda, parece que emitir el siguiente comando podría solucionarlo.

echo running > /sys/block/device-name/device/state

Creo que es posible que desee ver la sección 25.14.4: Cambio del estado de lectura / escritura de una unidad lógica en línea en este documento , sin embargo, le recomiendo reiniciar.

specialKevin
fuente
Gracias Kevin (Des) afortunadamente el problema se ha ido hace mucho tiempo, así que no puedo probarlo, pero esta parece ser la opción más prometedora.
cagenut
3
En un problema similar que experimenté / sys / block / device-name / device / state ya estaba configurado como 'en ejecución' y el comando anterior no resolvió el problema.
Se
3

Intenta usar:

mount -o remount,rw /mnt/fo
Desperatuss0ccus
fuente
Conozco FreeBSD, no Linux. Pero para fBSD es mount -rw /mnt/foo, así que este me parece el más adecuado.
Chris S
1
Nunca he tenido este trabajo en el escenario descrito en la pregunta. Una vez que el disco está marcado como de solo lectura debido a errores, siempre se ha reiniciado.
Alex
1
Editaré esto en el OP, pero Alex está aquí, el problema parece estar debajo del sistema de archivos: [root @ localhost ~] # mount -o remontaje, rw / mnt / foo mount: dispositivo de bloque / dev / mapper / mpath0 está protegido contra escritura, montaje de solo lectura
cagenut
1
¿Has intentado desmontar la partición y volver a montarla? He tenido errores de datos antes con una unidad, desmontar (o volver a montar, rw) me lo ha solucionado. Esto fue con unidades SATA (y EIDE / SCSI anteriores). Sin embargo, en su situación, me pregunto si el problema es que el canal de la unidad debe reiniciarse. Me pregunto si HDIO_DRIVE_RESET se envió a través de ioctl de alguna manera. blockdev se puede usar para forzar la relectura de la tabla de particiones que podría hacerlo. IDE expone esto con hdparm -w, quizás con sus unidades FC, tiene una manera de enviar el ioctl al canal.
2

Soy un fanático de prevenir el problema en primer lugar. La mayoría de las cajas UNIX empresariales volverán a intentar operaciones del sistema de archivos como siempre. Usted como administrador debe hacer algunos deberes antes de ajustar su configuración de MPIO. Si su aplicación debe esperar hasta que el dispositivo vuelva a un estado utilizable, entonces aquí hay una solución. En su /etc/multipath.conf asegúrese de que el tipo de dispositivo que le interesa tenga una configuración para "no_path_retry" establecida en "cola". Establecer esto hará que las E / S fallidas se pongan en cola hasta que haya una ruta válida. Hemos hecho esto para que nuestros cuadros EMC Symmtrix / DMX funcionen sobre el hipo en ciertas condiciones, fallas / recuperación de la unidad / controlador / ruta srdf.

Este enfoque ha ahorrado nuestro tocino innumerables veces y es nuestro estándar para cientos de cajas en una SAN multicabinet / multivendor con replicación para recuperación ante desastres.

Solo pensé que podría compartir con todos ustedes. Cuídate.

TomF
fuente
2

Tuve el problema, que resolví usando hdparm con la -ropción en subunidades de dispositivos lógicos y de múltiples rutas.

-r Obtiene / establece el indicador de solo lectura para el dispositivo. Cuando se establece, Linux no permite operaciones de escritura en el dispositivo.

c4f4t0r
fuente
1

¿Cree que está relacionado con la sección de este documento titulada ¿Por qué los sistemas de archivos ext3 en mi Red de área de almacenamiento (SAN) se vuelven repetidamente de solo lectura ?

Es un artículo bastante antiguo y habla sobre el canal de fibra, pero puede estar relacionado con su problema.

El conserje de Unix
fuente
Sí, no es ese error específico exacto ya que estoy ejecutando versiones mucho más nuevas que las que hacen referencia, pero todo tipo de situaciones similares pueden causarlo. El mundo de los canales de fibra, hbas / hba-firmware / hba-drivers, matriz de firmware, conmutador de firmware, diseño de estructura, dispositivo-mapper / multipathd config, lvm y ext3 es simplemente una gran cantidad de piezas móviles. Trabaje en entornos suficientes y verá este escenario causado por una bolsa de problemas similares pero no idénticos. La pregunta en cuestión es cómo recuperar / volver a montar sin reiniciar.
cagenut
0

Corrupción del sistema de archivos? Tratar:

dumpe2fs /dev/c/c | grep Filesystem\

Si está limpio de errores, entonces debe escanear y limpiar.

codycook
fuente
-4

Linux simplemente no se adapta suficientemente bien a las SAN de mediana y gran escala. DEBE darle un poco de cuidado y ajustar los tiempos de espera de E / S y el manejo de tiempo de espera de múltiples rutas, todos están más o menos en los valores predeterminados listos para escritorio.

(¿Recuerda "rechazar IO al dispositivo muerto"?)

darkfader
fuente
1
Realmente necesita respaldar declaraciones como "Linux no hace frente a SAN" y "valores predeterminados listos para escritorio" con referencias y hechos concretos.
Chris S
1
¿Tiempo de espera de E / S de disco predeterminado de 30 segundos? El hilo de arriba? La nota de RedHat (anticuada como puede ser) que indica que no pueden manejar una "notificación de cambio de estado" con gracia, de la forma en que se pretende. ¿Que Redhat por defecto puso los enlaces de múltiples rutas en una ubicación (/ var / lib) que no sería accesible en el momento de la carga del controlador de múltiples rutas? Que no puede deshabilitar en caliente recursivamente un hba de conexión en caliente PCI hba y temporalmente desconectar automáticamente todos los LUN dependientes hasta que se haya reemplazado. Que no tiene HW init multiproceso y que lleva "un tiempo" encontrar> 1k luns. Udev, siendo un script de shell ...
darkfader