Linux, como alterar o estado do HDD a partir do ReadOnly após uma falha temporária?

13

Neste momento, não há respostas para este problema.

Normalmente, após alguns problemas com leituras ou escritas para bloquear o dispositivo, o kernel decide alterar o sinalizador para TODO O DISPOSITIVO como somente leitura. Depois disso, qualquer escrita em qualquer partição / sistema de arquivos localizada neste dispositivo faz com que ela seja comutada como somente em conjunto com o estado do dispositivo, porque qualquer escrita é impossível.

Exemplo do dmesg, isso é simulação para o guest linux no windows8 usando o VirtualBox quando a desfragmentação leva a imagem do dispositivo:

[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. Problemas de escrita retornados dependem da condição do HDD
  2. A máquina host está sobrecarregada e, em seguida, as gravações de HDD do convidado Linux são expiradas
  3. Cabo FC ou dispositivo SAN (discos de matriz sobre Fibre Channel) está sobrecarregado
  4. Conexão perdida momentânea por FC ou FCoE. Talvez pacote FC perdido / timeouted

Nessas situações, o dispositivo é realmente de leitura / gravação, mas o kernel do Linux marca esse dispositivo internamente como somente leitura e é usado como somente leitura. Esta é a funcionalidade do kernel feita para prevenção de danos, mas é utilizável apenas em 1. ponto.

A pergunta é. Como dizer manualmente ao kernel, o dispositivo de bloco de HDD opera normalmente?

Se isso não funcionar, o dispositivo serve como somente leitura, como 'CD-ROM', e nenhum outro comando tem chance de funcionar corretamente, incluindo mount / remontar -o read-write, fsck e outros.

Unusable ansvers, really qualified as spam from people who wants to help, but doesn't understand about problem nature:

  1. Try remount as read-write (impossible, device is R-O)
  2. fsck this (what for? device is R-O, no repair is possible)
  3. 'I don't know' (first with sense, but unusable)
  4. 'Replace your device' *(usually the problem is something else)

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

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

  1. Remover módulo suporta acesso ao disco rígido especificado ou ao storage array. Infelizmente o dispositivo normalmente danificado mantém rootfs, ou o driver mantém o dispositivo e o dispositivo danificados que mantém o rootfs
  2. Remova o acesso do FC ao dispositivo e junte-se a ele novamente (fctools), nem sempre é possível, nem sempre funciona.
  3. Reinicie a máquina inteira. Normalmente, só isso é possível e sempre somos forçados a fazê-lo.

Nos pontos 1. e 2. dizemos ao kernel que desconectamos completamente o dispositivo e nos conectamos a ele novamente. O Kernel reconheceu isso como unindo o novo dispositivo de operação adequada. Podemos simular isso usando o dispositivo USB e a energia de remoção momentânea. O ponto 3. é a última chance e geralmente funciona. Mas por que devemos reiniciar tudo? Infelizmente, em todos os pontos, perdemos todas as atualizações de periódicos e buffers sujos.

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

    
por Znik 29.04.2013 / 15:18

3 respostas

9

tente com blockdev --setrw ou hdparm -r 0

    
por 29.04.2013 / 17:21
5

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

(assumindo que sda é o seu disco)

blockdev --setrw /dev/sda
mount /dev/sda -o remount,rw
touch /forcefsck
    
por 24.05.2016 / 22:40
2

Verifique esta página wiki, explica o erro lançado pela libata:

link

Pelo que vejo acima, você recebeu um problema de tempo limite e, de acordo com o documento mencionado:

Controller failed to respond to an active ATA command. This could be any number of causes. Most often this is due to an unrelated interrupt subsystem bug (try booting with 'pci=nomsi' or 'acpi=off' or 'noapic'), which failed to deliver an interrupt when we were expecting one from the hardware.

Você pode querer desabilitar o ACPI (confira como se basear em sua distro) ou checar seu kernel em busca de erros conhecidos e possivelmente atualizá-lo se não for o mais recente (ou degradá-lo).

    
por 02.05.2013 / 00:18