Este realmente me fez coçar a cabeça.
Primeiro, os dados são armazenados em backup com segurança , embora eu tenha perdido horas de trabalho de migração. Mas o resultado do que aconteceu me preocupou.
Eu estava migrando uma matriz de backup em um servidor mais antigo com um backplane SATA de 2,5 ". Os discos de 1 TB eram muito pequenos, por isso comecei a mudar para discos de 2 TB - usando os discos Seagate FireCuda 2.5 "2TB SSHD e SMR - a primeira vez que vejo discos SMR.
Na metade do processo, o pool do ZFS desapareceu sem deixar vestígios.
O armazenamento nessa matriz é backup. A configuração antiga era o Linux MD RAID-1 e eu iria migrar para um espelho ZFS enquanto trocava discos.
O primeiro disco a substituir foi / dev / sdc.
Estou usando discos inteiros para dispositivos ZFS (ou seja, / dev / sdc não / dev / sdc1).
O processo de migração foi (1) fazer backup de três discos externos, (2) quebrar o espelho RAID, (3) remover um disco de 1TB, (4) instalar o primeiro SSHD, (5) criar o pool ZFS, (6) copiar dados, (7) verificar, (8) parar o array MD, (9) substituir o segundo disco, depois (10) espelhar o pool.
Mas eu nunca passei de 7. Na reinicialização do servidor, o (então ainda único disco) pool desapareceu e não consigo encontrar nenhum vestígio dele, apesar de ter escrito 800GB de dados.
zdb -l / dev / sdc retorna:
--------------------------------------------
LABEL 0
--------------------------------------------
failed to unpack label 0
--------------------------------------------
LABEL 1
--------------------------------------------
failed to unpack label 1
--------------------------------------------
LABEL 2
--------------------------------------------
failed to unpack label 2
--------------------------------------------
LABEL 3
--------------------------------------------
failed to unpack label 3
Eu tentei um despejo binário dos primeiros 1MB de / dev / sdc. Isso é o que eu consegui:
# dd if=/dev/sdc bs=1048576 count=1 | xxd
0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
(...)
00fff60: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00fff70: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00fff80: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00fff90: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00fffa0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00fffb0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00fffc0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00fffd0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00fffe0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00ffff0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
E não é até eu passar 1GB de zeros antes de ver qualquer tipo de dado:
# dd if=/dev/sdc bs=1048576 count=1 skip=1032
(...)
0074fb0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0074fc0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0074fd0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0074fe0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0074ff0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0075000: 7f4a d799 69ad bcac dd98 5393 afeb 2745 .J..i.....S...'E
0075010: 2d23 af2b fdd9 2a6d c950 dd8b 0c8f 268d -#.+..*m.P....&.
0075020: 146b 2174 5ddd a757 e49e 2dfa 9e06 d0fc .k!t]..W..-.....
0075030: dfda 1ee7 ac17 cb41 8246 a7de ff39 d362 .......A.F...9.b
0075040: 67a0 c1e1 7f9b 6a4a 6e45 e2e3 1726 93e2 g.....jJnE...&..
0075050: 8310 6f20 5644 2a2c 0609 1927 9c22 d676 ..o VD*,...'.".v
0075060: 5950 cae7 f14c 938b 39b9 041e 960e 871b YP...L..9.......
0075070: 7dc6 54eb 5ee4 8cc9 836f adde 4aba dc3b }.T.^....o..J..;
0075080: 49c7 db23 5d0f 557d 8f63 3e43 9c5e 59c4 I..#].U}.c>C.^Y.
(...)
/ dev / sdc não mostra erros SMART e passa muito bem nos testes. Eu não tentei escrever nenhum dado para ele desde que essa estranheza começou. Eu definitivamente estou olhando para o disco correto, uma vez que ele relata sua capacidade como 2TB e é o único disco de 2TB instalado.
Alguém viu algo assim antes? Estou usando as ferramentas certas para calcular os primeiros 1GB e um bit de dados que, de alguma forma, foram completamente zerados? Isso poderia ser explicado por um cache flash defeituoso no disco SSHD ou algo estranho com zonas de gravação SMR?
Esse ponto em que os dados começam parece ser um número interessante (deslocamento de dd sendo 1048576x1032 e 0x75000 que parece ser um número redondo) mas eu não sei como entender isso.
Como complicação, enquanto eu comecei este trabalho na mesma sala que este servidor, estou a 4.000 km de distância por duas semanas, mas espero conseguir outra pessoa para trocar discos, se necessário. O segundo disco FireCuda ainda está para ser desembrulhado.
edições: terminologia corrigida, erros de limpeza