Linux, como alterar o estado do HDD de ReadOnly após travar temporariamente?

Question

Neste momento não há resposta para este problema.

Normalmente, após alguns problemas com leituras ou gravações no dispositivo de bloco, o kernel decide mudar o sinalizador para WHOLE DEVICE como somente leitura. Depois disso, qualquer gravação em qualquer partição/sistema de arquivos localizado neste dispositivo faz com que seja alternado como somente leitura junto com o estado do dispositivo, porque qualquer gravação é impossível.

Exemplo do dmesg, esta é uma simulação para Linux convidado no Windows8 usando VirtualBox quando a desfragmentação obtém a imagem do dispositivo convidado:

[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 o dispositivo sda mantendo rootfs sda1 é READONLY.

Na minha experiência, isso ocorre em situações:

1. O HDD está realmente danificado. Os problemas de gravação retornados dependem da condição do HDD
2. A máquina host está sobrecarregada e as gravações do HDD virtual do convidado do Linux atingiram o tempo limite
3. O cabo FC ou dispositivo SAN (discos de matriz sobre Fibre Channel) está sobrecarregado
4. Perda momentânea de conexão via FC ou FCoE. Talvez pacote FC perdido/tempo limite esgotado

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. Esta é uma funcionalidade do kernel criada para prevenção de danos, mas só pode ser usada no primeiro ponto.

Questão é. Como informar manualmente ao kernel que o dispositivo de bloco do disco rígido funciona normalmente?

Sem isso, o kernel serve o 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.

Respostas inutilizáveis, realmente qualificadas como spam de pessoas que querem ajudar, mas não entendem a natureza do problema:

1. Tente remontar como leitura e gravação (impossível, o dispositivo é RO)
2. fsck isso (para quê? O dispositivo é RO, nenhum reparo é possível)
3. 'Não sei' (primeiro com bom senso, mas inutilizável)
4. 'Substitua seu dispositivo' *(geralmente o problema é outro)

Alguém tem alguma fórmula para a pergunta acima? Sinalizador de mudança para dispositivo de bloco gravável que o reverte do estado somente leitura para leitura-gravação? Neste momento parece que ninguém sabe como.

São algumas soluções alternativas, mas geralmente semiutilizáveis ​​ou inutilizáveis:

1. Remover módulo oferece suporte ao acesso ao disco rígido ou matriz de armazenamento especificado. Infelizmente, geralmente o dispositivo danificado mantém rootfs, ou o driver mantém o dispositivo danificado e o dispositivo que mantém rootfs
2. Remova o acesso FC ao dispositivo e junte-se novamente (fctools), nem sempre é possível, nem sempre funciona.
3. Reinicie TODA a máquina. Normalmente só isso é possível e sempre somos forçados a isso.

Nos pontos 1. e 2. dizemos ao kernel que desconectamos completamente o dispositivo e conectamos a ele novamente. O Kernel reconheceu isso como uma adesão a um novo dispositivo funcionando corretamente. Podemos simular isso usando um dispositivo USB e remover a energia momentaneamente. O ponto 3. é a última chance e geralmente funciona. Mas por que devemos reiniciar tudo? Infelizmente, perdemos todas as atualizações dos diários e buffers sujos.

Observe que nas mesmas situações não tenho problemas com Windows (desktop e servidor).

Answer 1

tente com blockdev --setrwouhdparm -r 0

Answer 2

Como Jose Luis Martin sugeriu usar blockdev, meu 2cent é fazer uma remontagem rw e forcefsck

(assumindo que sda ​​é o seu disco)

blockdev --setrw /dev/sda
mount /dev/sda -o remount,rw
touch /forcefsck

Answer 3

Verifique esta página wiki, ela explica o erro gerado por libata:

https://ata.wiki.kernel.org/index.php/Libata_error_messages

Pelo que vejo acima, você tem um problema de tempo limite e conforme o documento mencionado:

O controlador não respondeu a um comando ATA ativo. Isso pode ser uma série de causas. Na maioria das vezes isso é devido a um bug não relacionado no subsistema de interrupção (tente inicializar com 'pci=nomsi' ou 'acpi=off' ou 'noapic'), que falhou em fornecer uma interrupção quando esperávamos uma do hardware.

Você pode desabilitar a ACPI (verifique como fazer com base na sua distribuição) ou verificar se há bugs conhecidos no kernel e possivelmente atualizá-lo se não for o mais recente (ou fazer downgrade).

Answer 4

###Olá, os comandos a seguir podem ajudar. Entretanto, não é seguro desmontar ou tentar modificar o sistema de arquivos raiz de uma unidade em execução. Em vez disso, inicialize o sistema a partir de um dispositivo inicializável.

1. Localize a unidade no sistema

$ mount | grep /dev/

2. Desmonte a unidade

$ sudo umount <your-mount-point-name>

3. Verifique e repare o sistema de arquivos com qualquer um dos seguintes comandos

###para um dispositivo ext4

$ sudo fsck.ext4 -f /dev/sda1

###para um dispositivo DOS

$ sudo dosfsck -a /dev/sda1

###ou você pode simplesmente executar o fsckcomando.

$ sudo fsck /dev/sda1

4. Remontar o dispositivo

$ sudo mkdir <your-mount-point-name>

Isso criará um novo ponto de montagem. Então corra:

$ sudo mount -o rw,uid=1000,gid=1000,user,exec,umask=003,blksize=4096 /dev/sdc1 /media/<your-mount-point-name>

Você está pronto para ir. No entanto, para mais detalhes sobre os comandos você pode conferirBaeldung