Acabei de descobrir o mesmo problema em dois servidores novos e idênticos instalados há apenas 9 meses. Não consegui gravar no disco de ambos porque o sistema o marcou como somente leitura. Os logs indicaram que houve algum tipo de erro de disco em ambos.
Observe que estou executando o KVM com vários convidados em cada um desses servidores. Todos os convidados estavam funcionando bem, mas o problema estava no host KVM. Isso provavelmente não importa, mas talvez seja pertinente. Ambos os sistemas têm apenasduas unidadescom software raid1 e LVM no topo. Cada convidado KVM também possui sua própria partição LVM.
Ambos os sistemas mostravam uma matriz RAID1 degradada ao analisar o /proc/mdstat.
Então reiniciei um dos sistemas e ele me disse que precisava executar manualmente o fsck. Então eu fiz isso. Pareceu resolver os problemas e uma reinicialização fez com que o sistema voltasse a funcionar normalmente. O mesmo processo também funcionou no segundo servidor.
Em seguida, corri mdadm --manage /dev/md0 --add /dev/sdb1para adicionar a unidade com falha de volta ao array. Isso funcionou bem em ambos os servidores. Durante a próxima hora ou mais, a observação /proc/mdstatmostrou progresso na sincronização das unidades. Depois de cerca de uma hora, um sistema foi concluído e /proc/mdstatmostrou que tudo funcionava bem com o [UU].
No entanto, no outro sistema, após cerca de 1,5 horas, a carga do sistema disparou e nada respondeu. Poucos minutos depois, tudo voltou. Mas olhar /proc/mdstatagora mostra o seguinte:
root@bond:/etc# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[2] sdb1[1]
293033536 blocks [2/1] [_U]
unused devices: <none>
Como você pode ver, parece que não está mais sincronizando. A porcentagem concluída, o tempo restante, etc. não são mais exibidos. No entanto, a execução mdadm --detail /dev/md0mostra isso:
root@bond:/etc# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Mon Nov 30 20:04:44 2009
Raid Level : raid1
Array Size : 293033536 (279.46 GiB 300.07 GB)
Used Dev Size : 293033536 (279.46 GiB 300.07 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Sep 10 23:38:33 2010
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
UUID : 4fb7b768:16c7d5b3:2e7b5ffd:55e4b71d
Events : 0.5104310
Number Major Minor RaidDevice State
2 8 1 0 spare rebuilding /dev/sda1
1 8 17 1 active sync /dev/sdb1
O resultado final parece indicar que o sobressalente está sendo reconstruído. Por que é um sobressalente? O sistema está reportando ambos os dispositivos como limpos. Ficou assim por horas. As unidades são VelociRaptors pequenos e rápidos de 300 GB e 10K RPM, então eu acho que já teriam sido sincronizados. A tentativa de adicionar novamente indica que o dispositivo está ocupado:
root@bond:/etc# mdadm /dev/md0 --re-add /dev/sda
mdadm: Cannot open /dev/sda: Device or resource busy
Executar dmesg no servidor "bom" mostra isso no final:
[ 4084.439822] md: md0: recovery done.
[ 4084.487756] RAID1 conf printout:
[ 4084.487759] --- wd:2 rd:2
[ 4084.487763] disk 0, wo:0, o:1, dev:sda1
[ 4084.487765] disk 1, wo:0, o:1, dev:sdb1
No servidor "ruim", as últimas 4 linhas são repetidas centenas de vezes. No servidor "bom", eles aparecem apenas uma vez.
As unidades ainda estão sincronizando? Será que esta “reconstrução” terminará? Eu só preciso ser mais paciente? Se não, o que devo fazer agora?
ATUALIZAR:
Acabei de reiniciar e a unidade começou a sincronizar novamente. Depois de quase 2 horas, aconteceu a mesma coisa descrita acima (ainda recebo um [_U]). No entanto, consegui ver os logs do dmesg antes que os pedaços de impressão do RAID1 conf consumissem tudo:
[ 6348.303685] sd 1:0:0:0: [sdb] Unhandled sense code
[ 6348.303688] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 6348.303692] sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
[ 6348.303697] Descriptor sense data with sense descriptors (in hex):
[ 6348.303699] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 6348.303707] 22 ee a4 c7
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
Então, talvez a pergunta que eu deveria fazer seja "Como executo o fsck em um disco sobressalente em um conjunto de ataques?"
Responder1
Não tenho certeza se você realmente substituiu a(s) unidade(s) com falha. Porque seus sintomas fariam sentido para mim se você adicionasse novamente a unidade defeituosa; nesse caso, há uma boa chance de a unidade ter travado. Se você adicionou novamente a unidade defeituosa, há erros subsequentes em/var/log/messages ou dmesg?
(Aliás, eu recomendo fortemente não adicionar novamente uma unidade defeituosa a uma matriz RAID. Se a falha corrompeu os dados no prato, você pode descobrir que, ao adicioná-los de volta à matriz, a ressincronização deixa o arquivo corrompido no disco, e da próxima vez que você ler os arquivos, será uma questão de saber se você obterá dados bons ou ruins, dependendo de qual disco responder primeiro. Já vi isso acontecer.)
Responder2
Usar mdadm --details listará uma unidade como sobressalente durante a reconstrução. Após a conclusão da reconstrução, ele não aparecerá mais como sobressalente.
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
A primeira linha indica que houve falha na realocação e os dados não foram lidos. As três linhas a seguir indicam que os dados não puderam ser lidos e listam os setores que estão ilegíveis.
Como Rodger apontou, a unidade está ruim, não a adicione novamente. Nunca é uma boa ideia adicionar novamente uma unidade que falhou. Puxe a unidade e substitua-a. Se desejar, execute o diagnóstico na unidade com falha, mas somente depois de ela ter sido retirada e substituída.
Responder3
Primeiro, sim, livre-se de qualquer disco que esteja gerando erros de leitura que acabem no arquivo de log. Isso significa que a realocação do bloco defeituoso falhou e/ou a unidade está perto de morrer.
Eu sugiro que para resgatar seus dados você use um CD de resgate do Linux comohttp://ubuntu-rescue-remix.org/para usar o ddrescue. Isso pode fazer uma cópia da imagem para uma nova partição de disco e fará muitas tentativas, etc., para tentar recuperar sua partição. Monte uma unidade USB ou outra partição
mkdir /tmp/x && montar /dev/sdd1 /tmp/x
para manter o arquivo de log do ddrescue - então você pode parar o ddrescue (ctrl-C) e reiniciá-lo mais tarde do mesmo ponto.
Faça uma partição no novo disco um pouco maior que o disco antigo. Você não precisa usar o disco inteiro!
Inicialize o CD de recuperação com "nodmraid" como parâmetro de inicialização do kernel. Se estiver usando o live CD do Ubuntu, instale o RAID e o LVM se estiver usando
apt-get instalar mdadm lvm2 gddrescue
você precisará estar na internet para que isso funcione). Caso contrário, use o CD de recuperação do Ubuntu para a etapa ddrescue. Troquei entre o CD de resgate para execuções do ddrescue e o CD ao vivo para o trabalho do grub e do fsck.
Supondo que /dev/sdb seja seu disco de origem com falha e /dev/sdx seja seu novo disco e /mnt/x seja uma chave USB ou uma partição em outro disco que foi montado. Vocêprecisaro arquivo de log ddrescue, realmente! Pois ele rastreia o andamento do ddrescue e permite que ele seja interrompido.
Conformehttp://www.forensicswiki.org/wiki/Ddrescue
ddrescue --no-split /dev/sdb /dev/sdX arquivo de imagem /mnt/x/logfile
então
ddrescue --direct --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
então
ddrescue --direct --retrim --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
Não tenha medo de pressionar Ctrl-C no processo se estiver demorando horas para recuperar um único setor. Basta passar para a próxima etapa (a etapa 1 deve ser bem-sucedida, não importa o que aconteça). A última etapa tenta recuperar as últimas migalhas de dados utilizáveis.
Você também terá que fazer
mdadm --create /dev/md99 --level-1 --raid-devices=2 faltando /dev/sdX
para criar uma nova matriz RAID usando o novo disco, isso grava um novo superbloco RAID na partição (nos últimos 64K a 128K no final da partição).
Remova seu antigo disco com falha /dev/sdb do sistema para que não fique visível para o Linux.
Torne seu disco RAID de origem acessível. Você pode ter que usar o parâmetro "nodmraid" para o kernel de inicialização do kernel, pois tive problemas com o CD de resgate do Ubuntu e acabei usando o live CD do Ubuntu (10.4) onde o nodmraid está nas opções F6. Você só precisa usar
mdadm --assemble /dev/md99 /dev/sdX
Em seguida, fsck ou faça qualquer verificação necessária nos dados na matriz RAID md99 (usei o vgscan e consegui ver os LVs do LVM para executar a verificação). Eu uso XFS para mythtv, mas o comando xfs_check travou meu sistema, mas xfs_repair estava OK.
Monte o diretório /boot do seu novo /dev/sdX
monte /dev/mapper/my_vg/root_lv /tmp/x
em seguida, coloque um novo registro de inicialização GRUB no novo disco RAID /dev/sdX (somente se você inicializar a partir do RAID!)
grub-setup -d /tmp/x/boot/grub /dev/sdX
agora você tem um array RAID (quase) inicializável. Você também pode fazer a configuração usando o próprio GRUB ou usar dd para copiar os primeiros 446 bytes de /dev/sdb para /dev/sdX. APENAS os primeiros 446 bytes, o resto do primeiro setor é a sua tabela de partições, que você encherá muito se copiar mais! Você também pode ter que fazer o mesmo para o primeiro setor em sua partição /dev/sdX1 (digamos). Faça backup de todos os setores que você irá sobrescrever, também usando dd.
Se estiver usando o grub2 e estiver inicializando a partir do RAID, você descobrirá que o UUID da matriz RAID foi alterado e sua inicialização falhará. Edite a linha de comando de inicialização (e no painel de inicialização do Grub) para remover splash e quiet, para que você possa ver o que está acontecendo. Então, após a falha na inicialização, você será deixado no initramfs.
mdadm --assemble /dev/md99 /dev/sdX
em seguida, verifique /proc/mdstat para ter certeza de que o array está lá. Se for, basta "sair" e esperamos que sua sub-rotina de inicialização GRUB funcione bem (a minha foi configurada para usar LVM, então apenas encontrou os LVs no dispositivo RAID quando havia algum dispositivo RAID lá, apenas procurou pelo LV). Depois de inicializado, você estará quase pronto.
O arquivo de imagem initrd (arquivo cpio compactado em gzip) contém uma cópia do mdadm.conf usado durante o processo de inicialização, visível e editável como /etc/mdadm/mdamdm.conf durante o processo de inicialização. Se você conseguir inicializar seu sistema normalmente, basta atualizar o initramfs usando
atualizar-initramfs -u
Se você não conseguir inicializar o sistema devido ao UUID incompatível no arquivo mdadm.conf
Esteja ciente de que seu dispositivo de destino /dev/sdX pode aparecer como /dev/sdY quando você inicializa de uma maneira diferente (Grub, resgate, inicialização real).
A propósito, a menos que você esteja usando RAID5 e esteja realmente interessado no alinhamento de blocos, eu usaria uma partição para sua matriz RAID, você não precisa usar um disco inteiro (especialmente se estiver substituindo um disco de 1 TB por um de 2 TB um). Você sempre pode adicionar outra partição e uma segunda matriz RAID posteriormente para usar todos os 2 TB.
Ufa! Feito!