É um problema relativamente comum quando algo dá errado em uma SAN do ext3 para detectar erros de gravação no disco e remontar o sistema de arquivos somente leitura. Tudo bem, apenas quando a SAN é corrigida, não consigo descobrir como remontar a leitura / gravação do sistema de arquivos sem reiniciar.
Ver:
[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
Tudo bem, agora eu arranco o LUN por baixo dele.
[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
Ele só pensa que é somente leitura, na realidade nem está lá.
[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
Como ele ainda lembra que o arquivo 'bar' está lá ... mistério, mas não é importante no momento. Agora, apresento novamente o 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]
Ótimo, certo? Diz [rw] bem ali. Não tão rápido:
[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system
OK, não faz isso automaticamente, vou dar um empurrãozinho:
[root@localhost ~]# mount -o remount /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only
Diabos você é:
[root@localhost ~]# mount -o remount,rw /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only
Noooooooooo.
Eu tentei todos os tipos de comandos mount / tune2fs / dmsetup diferentes e não consigo descobrir como fazê-lo desmarcar o dispositivo de bloco como protegido contra gravação. A reinicialização corrigirá, mas eu prefiro fazê-lo on-line. Uma hora de pesquisar no google também não me levou a lugar algum. Salve-me ServerFault.
3
hmm, algumas perguntas 'É um problema relativamente comum quando algo dá errado em uma SAN' por que sua SAN é tão confiável? Eu verificaria isso primeiro? Você já tentou desmontar com umount e montá-lo novamente? Existe uma boa razão para você precisar fazer uma remontagem? Normalmente, só preciso remontar meus sistemas de arquivos raiz após a manutenção.
—
The Unix Janitor
o umount salta nos manipuladores de arquivos abertos, que geralmente são de processos que você preferiria sair com segurança.
—
cagenut
Eu tenho um problema semelhante no qual, após um problema de SAN, os discos das VMs são somente leitura e a tentativa de remontar causa o mesmo erro no OP. As VMs estão no esxi 4.1 com armazenamento de canal de fibra. A reinicialização da VM corrige o problema. Pessoalmente, não acho que isso tenha algo a ver com o multipath. Certamente deve haver uma maneira de corrigir sem reiniciar, principalmente porque alguns serviços (apache) tendem a continuar executando em um FS somente leitura.
—
Will
Eu vim aqui procurando uma solução para o meu próprio problema (que é diferente, um disco corrompido). Eu sorri em vez disso. +1 para "O inferno que você é"
—
user1207217 23/03
Estou com o mesmo problema, mas estou usando o LVM. O mesmo lvdisplay me daria uma "falha na leitura após 0 de 4096 em 449197309952: Erro de entrada / saída" até que eu fiz um "caminho múltiplo -r", então o LVM começou a exibir tudo certo, sem erros. Ainda não consigo remontar a partição. Também não é possível desmontar, diz que o dispositivo está ocupado. Se eu encerrar todos os processos usando o dispositivo, posso desmontar e remontar com sucesso, mas eu prefiro apenas ser capaz de remontar o dispositivo de leitura e escrita, como eu deveria ser capaz de ...
—
mpontes