Versão resumida: fazemos regularmente backup de arquivos em uma unidade RD1000, mas periodicamente a tabela de partições neste disco é corrompida ou é lida incorretamente, e não sei por quê. Sobrescrever a tabela de partição corrigiu o problema todas as vezes até o momento. Nenhuma perda de dados até agora, mas quero descobrir por que isso está acontecendo.
Agora, para a versão longa.
Configuramos nossos cartuchos RD1000 da seguinte maneira: O sfdisk é usado para criar uma única partição usando todo o espaço disponível. Nessa partição, criamos um contêiner LUKS, usando o cryptsetup, para manipular a criptografia. Colocamos o sistema de arquivos dentro do contêiner LUKS.
Normalmente, se eu inspecionar manualmente os primeiros bytes da partição, posso ver claramente o cabeçalho LUKS:
# hexdump -C -n 80 /dev/sdb1
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 63 62 63 2d 65 73 73 69 |........cbc-essi|
00000030 76 3a 73 68 61 32 35 36 00 00 00 00 00 00 00 00 |v:sha256........|
00000040 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 |........sha1....|
00000050
Mas quando o problema ocorre, este mesmo comando mostra bytes totalmente diferentes. O cabeçalho LUKS parece ter desaparecido:
# hexdump -C -n 80 /dev/sdb1
00000000 da 86 6d ad 3a 6e 2f 4f 4e 03 f3 c4 2d 7d 46 55 |..m.:n/ON...-}FU|
00000010 a9 8b b1 63 ac 4e 40 57 f4 27 b5 99 42 79 5e 4b |...c.N@W.'..By^K|
00000020 f4 db 39 ea 76 57 92 f9 d0 e3 43 61 8c f0 fc e5 |..9.vW....Ca....|
00000030 07 60 39 96 f3 97 72 fe c6 0d 77 ed bd ff b0 08 |.'9...r...w.....|
00000040 b1 bb 24 d3 d0 b5 fe 40 b6 96 10 95 86 1d 8d 3c |..$....@.......<|
Pensando que talvez o sistema operacional tenha armazenado em cache a tabela de partições incorretamente, tentei forçar uma releitura usando todos os métodos a seguir:
partprobe
hdparm -z /dev/sdb
sfdisk -R /dev/sdb
... sem sucesso. Mas se eu reescrever completamente a tabela de partições usando sfdisk, então de repente tudo começa a funcionar novamente. Eu também noto que quando recrio a tabela de partição, o sfdisk está reportando um número diferente de blocos:
Disk /dev/disk/by-id/scsi-1DELL_RD1000_10220BD15C13112010: 38912 cylinders, 255 heads, 63 sectors/track
Old situation:
Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End MiB #blocks Id System
/dev/disk/by-id/scsi-1DELL_RD1000_10220BD15C13112010p1 0+ 305234 305235- 312560608+ 83 Linux
/dev/disk/by-id/scsi-1DELL_RD1000_10220BD15C13112010p2 0 - 0 0 0 Empty
/dev/disk/by-id/scsi-1DELL_RD1000_10220BD15C13112010p3 0 - 0 0 0 Empty
/dev/disk/by-id/scsi-1DELL_RD1000_10220BD15C13112010p4 0 - 0 0 0 Empty
New situation:
Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End MiB #blocks Id System
/dev/disk/by-id/scsi-1DELL_RD1000_10220BD15C13112010p1 0+ 305234 305235- 312560639+ 83 Linux
/dev/disk/by-id/scsi-1DELL_RD1000_10220BD15C13112010p2 0 - 0 0 0 Empty
/dev/disk/by-id/scsi-1DELL_RD1000_10220BD15C13112010p3 0 - 0 0 0 Empty
/dev/disk/by-id/scsi-1DELL_RD1000_10220BD15C13112010p4 0 - 0 0 0 Empty
Eu tentei tudo o que sei para tentar neste momento e estou à procura de ideias. Por que o número de blocos mudou e por que o sistema operacional continua perdendo o controle de onde a partição realmente começa?
Esses problemas estão ocorrendo em um servidor que executa o RHEL 5.11. No entanto, temos outros servidores executando a mesma versão do RH, que não tiveram o mesmo problema