Neste momento não há ansver para este problema.
Geralmente, após alguns problemas com leituras ou escritas para bloquear o dispositivo, o kernel decide alternar o sinalizador para TODO O DISPOSITIVO como somente leitura. Após isso, qualquer gravação em qualquer partição / sistema de arquivos localizado neste dispositivo causa alterná-lo como somente leitura junto com o estado do dispositivo, porque quaisquer gravações são impossíveis.
Exemplo do dmesg, esta é uma simulação para o Linux convidado no windows8 usando o VirtualBox quando a desfragmentação leva a imagem do dispositivo para convidados:
[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.
Depois disso, remonte a causa:
mount / -o remount,rw
mount: cannot remount block device /dev/sda1 read-write, is write-protected
porque TODO dispositivo sda mantendo rootfs sda1 é READONLY.
Na minha experiência, isso ocorre em situações:
- HDD está realmente danificado. Os problemas de gravação retornados dependem da condição do disco rígido
- A máquina host está sobrecarregada e, em seguida, as gravações do HDD virtual do convidado Linux são atingidas pelo tempo limite
- O cabo FC ou o dispositivo SAN (discos da matriz sobre o Fibre Channel) está sobrecarregado
- Momentaneamente perdeu a conexão pelo FC ou FCoE. Talvez pacote FC perdido / com tempo limite
Nessas situações, o dispositivo é realmente de leitura e gravação, mas o kernel do linux marca esse dispositivo internamente como somente leitura e é usado como somente leitura. Essa é a funcionalidade do kernel criada para prevenção de danos, mas é utilizável apenas no 1. ponto.
Questão é. Como dizer manualmente ao kernel, o dispositivo de bloco de disco rígido opera normalmente?
Sem isso, o kernel serve ao dispositivo como somente leitura, como 'CD-ROM', e nenhum outro comando tem chance de funcionar corretamente, incluindo mount / remount -o read-write, fsck e outros.
Anversas inutilizáveis, realmente qualificadas como spam de pessoas que desejam ajudar, mas não entendem sobre a natureza do problema:
- Tente remontar como leitura e gravação (impossível, o dispositivo é RO)
- fsck this (para quê? o dispositivo é RO, nenhum reparo é possível)
- 'Eu não sei' (primeiro com sentido, mas inutilizável)
- 'Substitua o seu dispositivo' * (geralmente o problema é outra coisa)
Alguém tem alguma fórmula para a pergunta acima? Alternar sinalizador para dispositivo de bloco gravável que o reverte do estado somente leitura para o estado leitura / gravação? Neste momento, parece que ninguém sabe como.
São algumas soluções alternativas, mas geralmente semiusable ou inutilizáveis:
- O módulo Remover suporta o acesso ao disco rígido ou ao storage array especificado. Infelizmente, o dispositivo geralmente danificado mantém o rootfs ou o driver mantém o dispositivo danificado e o dispositivo que mantém o rootfs
- Remova o acesso do FC ao dispositivo e junte-o novamente (fctools), nem sempre possível, nem sempre funcionando.
- Reinicie a máquina inteira. Normalmente, apenas isso é sempre possível e sempre somos forçados a fazê-lo.
Nos pontos 1. e 2., informamos ao kernel que desconectamos completamente o dispositivo e nos conectamos a ele novamente. O kernel reconheceu isso como ingressar no novo dispositivo de operação adequada. Podemos simular isso usando o dispositivo USB e remover momentaneamente a energia. O ponto 3. é a última chance e geralmente funciona. Mas por que devemos reiniciar tudo? Infelizmente, em todos os momentos, perdemos todas as atualizações de periódicos e buffers sujos.
Observe que, nas mesmas situações, não tenho problemas com o Windows (desktop e servidor).