É um problema relativamente comum quando algo está errado em uma SAN para que o ext3 detecte erros de gravação no disco e remonte o sistema de arquivos somente leitura. Tudo bem, só quando a SAN é fixa eu não consigo descobrir como re-re-montar o sistema de arquivos de leitura-gravação sem reiniciar.
Eis:
[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 puxo o LUN de dentro 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 não 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 agora. Agora eu apresento 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 né? Aqui diz [rw]. 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
O inferno que 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 obtê-lo para desmarcar o dispositivo de bloco como protegido contra gravação. A reinicialização consertará, mas prefiro fazê-lo on-line. Uma hora de googling não me levou a lugar nenhum. Salve-me ServerFault.
Recentemente, encontrei esse problema e resolvi-o reinicializando, mas após investigações posteriores, parece que a emissão do seguinte comando pode resolvê-lo.
echo running > /sys/block/device-name/device/state
Eu acho que você pode querer olhar para veja a seção 25.14.4: Alterando o Estado de Leitura / Gravação de uma Unidade Lógica On-line neste documento , no entanto, recomendo a reinicialização.
Tente usar:
mount -o remount,rw /mnt/fo
Sou fã de evitar o problema em primeiro lugar. A maioria das caixas UNIX da empresa tentará novamente as operações do sistema de arquivos como sempre. Você, como administrador, precisa fazer um pouco de lição de casa antes de ajustar sua configuração do MPIO. Se o seu aplicativo deve esperar até que o dispositivo retorne a um estado utilizável, então aqui está uma solução. Em seu /etc/multipath.conf, certifique-se de que o tipo de dispositivo de que você gosta tenha uma configuração para "no_path_retry" definida como "fila". Definir isso fará com que as E / Ss com falha fiquem na fila até que haja um caminho válido. Fizemos isso para que as caixas EMC Symmtrix / DMX trabalhassem com soluços sob certas condições falhas / recuperação do caminho / controladora / srdf. Quando você quer falhar o dispositivo manualmente durante uma falha, fica mais complicado, pois você precisará usar ferramentas como o dmsetup para fazer I / O / flush / fail ou alterar temporariamente o arquivo multipath.conf e verificar novamente os dispositivos .... etc.
Essa abordagem salvou nosso bacon inúmeras vezes e é nosso padrão para centenas de caixas em uma SAN multicabinet / multivendor com replicação para recuperação de desastres.
Pensei em compartilhar com todos vocês. Tome cuidado.
Eu tive o problema, que resolvi usar hdparm com a opção -r em subdrives de dispositivos lógicos multipath.
-r Get/set read-only flag for the device. When set, Linux disallows write operations on the device.
Você acha que está relacionado a a seção neste documento intitulada Por que os sistemas de arquivos ext3 no meu A Rede de Área de Armazenamento (SAN) repetidamente se torna somente leitura ?
É um artigo bastante antigo e está falando de canal de fibra, mas pode estar relacionado ao seu problema.
Corrupção do sistema de arquivos? Experimente:
dumpe2fs /dev/c/c | grep Filesystem\
Se estiver limpo com erros, você precisará digitalizar e limpar.
O Linux simplesmente não se dá bem com as SANs de médio e grande porte. Você DEVE dar alguns cuidados e ajustar os tempos limite de IO e o tratamento de tempo limite de vários caminhos, eles são todos muito bem em padrões prontos para desktop.
(Lembre-se de "rejeitar IO para dispositivo morto"?)