dr: como eu faria para consertar um bloco defeituoso em 1 disco em uma matriz RAID1?
Mas, por favor, leia tudo isso para saber o que já tentei e possíveis erros em meus métodos. Tentei ser o mais detalhado possível e espero realmente algum feedback
Esta é a minha situação: tenho dois discos de 2 TB (mesmo modelo) configurados em um array RAID1 gerenciado por mdadm. Cerca de 6 meses atrás, notei o primeiro bloqueio incorreto quando a SMART o relatou. Hoje percebi mais e agora estou tentando consertar.
Esta página COMO FAZERparece ser o único artigo ao qual todos vinculam para corrigir bloqueios defeituosos que a SMART está relatando. É uma página ótima, cheia de informações, porém está bastante desatualizada e não aborda minha configuração específica. Aqui está como minha configuração é diferente:
- Em vez de um disco, estou usando dois discos em uma matriz RAID1. Um disco está relatando erros enquanto o outro está bem. O HOWTO foi escrito com apenas um disco em mente, o que levanta várias questões como 'devo usar este comando no dispositivo de disco ou no dispositivo RAID'?
- Estou usando GPT, que o fdisk não suporta. Em vez disso, tenho usado o gdisk e espero que ele esteja me fornecendo as mesmas informações de que preciso
Então, vamos direto ao assunto. Isso é o que eu fiz, mas não parece estar funcionando. Sinta-se à vontade para verificar meus cálculos e métodos em busca de erros. Os erros de relatório do disco são /dev/sda:
# smartctl -l selftest /dev/sda
smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.4.4-2-ARCH] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 12169 3212761936
Com isso, concluímos que o erro reside no LBA 3212761936. Seguindo o HOWTO, utilizo o gdisk para encontrar o setor inicial a ser usado posteriormente na determinação do número do bloco (já que não posso usar o fdisk, pois ele não suporta GPT):
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): CFB87C67-1993-4517-8301-76E16BBEA901
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 3907029134 1.8 TiB FD00 Linux RAID
Usando tunefs, acho que o tamanho do bloco é 4096. Usando esta informação e o cálculo do HOWTO, concluo que o bloco em questão é ((3212761936 - 2048) * 512) / 4096 = 401594986.
O HOWTO então me orienta para debugfsver se o bloco está em uso (eu uso o dispositivo RAID pois ele precisa de um sistema de arquivos EXT, esse foi um dos comandos que me confundiu pois a princípio não sabia se deveria usar / dev/sda ou /dev/md0):
# debugfs
debugfs 1.42.4 (12-June-2012)
debugfs: open /dev/md0
debugfs: testb 401594986
Block 401594986 not in use
Portanto, o bloco 401594986 é um espaço vazio, devo poder escrever sobre ele sem problemas. Antes de escrever, porém, tento ter certeza de que, de fato, não pode ser lido:
# dd if=/dev/sda1 of=/dev/null bs=4096 count=1 seek=401594986
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000198887 s, 20.6 MB/s
Se o bloco não pudesse ser lido, eu não esperaria que isso funcionasse. No entanto, isso acontece. Repito usando /dev/sda, /dev/sda1, /dev/sdb, /dev/sdb1, /dev/md0e +-5 para o número do bloco para pesquisar o bloco defeituoso. Tudo funciona. Encolho os ombros e sigo em frente e confirmo a gravação e sincronização (eu uso /dev/md0 porque imaginei que modificar um disco e não o outro poderia causar problemas, desta forma ambos os discos substituem o bloco defeituoso):
# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=401594986
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000142366 s, 28.8 MB/s
# sync
Eu esperaria que a gravação no bloco defeituoso fizesse com que os discos reatribuíssem o bloco para um bloco bom, no entanto, a execução de outro teste SMART mostra uma diferença diferente:
# 1 Short offline Completed: read failure 90% 12170 3212761936
De volta à estaca zero. Então, basicamente, como eu consertaria um bloco defeituoso em 1 disco em uma matriz RAID1? Tenho certeza de que não fiz algo corretamente...
Obrigado pelo seu tempo e paciência.