17 votos

¿Cómo se puede volver a montar una ext3 fs readwrite después se monta readonly de un error de disco?

Es un problema relativamente común, cuando algo va mal en una SAN para ext3 para detectar los errores de escritura de disco y vuelva a montar el sistema de ficheros de sólo lectura. Eso es todo bien y bueno, sólo cuando el SAN es fijo que no puedo averiguar cómo re-re-montar el sistema de archivos de lectura-escritura sin necesidad de reiniciar.

He aquí:

[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 me tire el LUN salir de debajo de ella.

[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

Sólo piensa que es sólo de lectura, en realidad ni siquiera existe.

[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 es que todavía se acuerda de que 'bar' archivo de estar allí... misterio, pero no es importante ahora. Ahora puedo volver 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]

Gran derecha? Dice [rw] de allí. No tan rápido:

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

OK, no lo hace automáticamente, voy a darle un poco de empuje:

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

El infierno que son:

[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 mount/tune2fs/dmsetup comandos y no puedo averiguar cómo llegar a la onu-la bandera de que el dispositivo de bloque como protegido contra escritura. Reiniciar la voluntad de arreglarlo, pero prefiero hacerlo on-line. Una hora de búsqueda en google me ha llevado a ningún lugar. Sálvame ServerFault.

6voto

specialKevin Puntos 41

Hace poco me encontré con este problema y lo soluciono reiniciando pero después de más investigación aparece el siguiente comando podría solucionarlo.

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

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Storage_Administration_Guide/index.html#task_controlling-scsi-command-timer-onlining-devices

Creo que se puede buscar en 25.14.4. Cambiar el Estado de Lectura y Escritura de una Línea de Unidad Lógica en el mismo documento, sin embargo yo recomiendo reiniciar.

3voto

TomF Puntos 11

Yo soy un fan de la prevención de la cuestión en primer lugar. La mayoría de enterprise en UNIX casillas volverá a intentar sistema de ficheros operaciones como siempre. Usted como administrador necesidad de hacer algunas tareas antes de sintonización del MPIO de configuración. Si su aplicación debe esperar hasta que el dispositivo de retorno a un estado utilizable, entonces aquí es una solución. En el /etc/multipath.conf asegúrese de que el tipo de dispositivo que usted quiere tiene un valor de "no_path_retry" set "de cola". La configuración de este causará error de I/Os a la cola hasta que haya una ruta de acceso válida. Hemos hecho esto para nuestro EMC Symmtrix/DMX cuadros de trabajo sobre el hipo bajo ciertas condiciones de controlador de unidad/srdf fallos en la ruta/recuperación. Cuando usted quiere fallar el dispositivo manualmente durante una falla se vuelve más complicado, ya que tendrás que usar herramientas como dmsetup a ras/no me/Os o cambiar temporalmente el multipath.conf archivo y vuelva a escanear dispositivos....etc.

Este enfoque ha salvado nuestras tocino infinidad de veces y es nuestro estándar de cientos de cajas de multicabinet/multifabricante SAN con replicación de recuperación de desastres.

Sólo pensé que podría compartir con todos vosotros. Cuidado de la toma.

2voto

c4f4t0r Puntos 1749

he tenido algún problema, decidí utilizar hdparm utilizar la opción-r en subdives de lógica dispositivos multipath

-r     Get/set read-only flag for the device.  When set, Linux disallows write operations on the device.

1voto

Kirill Osenkov Puntos 3902

¿Cree usted que es la relativa a la

http://www.redhat.com/magazine/026dec06/features/tips_tricks/

consulte la sección sobre el por Qué los sistemas de archivos ext3 en mi Red de Área de Almacenamiento (SAN) repetidamente a ser de sólo lectura?

es un artículo viejo, y está hablando de canal de fibra. Puede estar relacionada con su problema.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X