Erros do sistema de arquivos ao restaurar muitos arquivos

0

Eu tinha um disco rígido externo que montei internamente. Ele veio formatado com NTFS e eu queria mudar para o ext4. Então copiei tudo o que queria manter em outras unidades, criei uma nova tabela de partições (GPT) com uma única partição ext4 e agora estou tentando copiar tudo de volta. Estou usando rsync -a --info=progress2 para a maioria das operações de cópia.

Meu problema é que, depois de 100 GB ou mais, tenho a tendência de receber erros estranhos:

rsync: write failed on "somepath": Read-only file system (30)
rsync error: error in file IO (code 11) at receiver.c(389) [receiver=3.1.0]

Se eu tentar listar o diretório em que o rsync estava trabalhando quando ele falhou, vejo resultados estranhos:

drwx------  3 pdaddy pdaddy 4096 Aug 28 2011 subdirectory1
drwx------  3 pdaddy pdaddy 4096 Mar 12 2014 subdirectory2
d?????????  ? ?      ?         ?           ? subdirectory3
d?????????  ? ?      ?         ?           ? subdirectory4

Tentando listar os diretórios com pontos de interrogação em suas listagens, e até mesmo alguns deles sem, me dá:

ls: reading directory subdirectory3: Input/output error
total 0

Até mesmo o fdisk tem erros:

~ % fdisk /dev/sde   
fdisk: unable to read /dev/sde: Input/output error

Se eu tentar desmontar a unidade, o comando umount será interrompido. Eu corri htop e vi que umount estava usando 100% de um núcleo da CPU. Presumi que estava cometendo diários ou algo assim, então deixei passar a noite toda uma vez, mas estava no mesmo estado da manhã. Emitir sudo reboot ou sudo init 6 enquanto umount está suspenso resulta em outro terminal suspenso. Eu tenho que segurar o botão de energia. Só agora eu tentei reiniciar sem desmontar explicitamente, e ele ficou com uma tela preta (o monitor foi dormir), e nenhuma resposta via ssh ou teclado.

Após um ciclo de energia strong, desmontei o disco e fiz sudo fsck.ext4 -f /dev/sde1 e não houve erros. Eu verifiquei os arquivos, e eles pareciam estar todos lá e uma amostra deles estava correta.

Assumi que os erros tinham algo a ver com o diário ser muito grande (talvez ele esteja limitado a um tamanho máximo?), então eu remontei com -o data=writeback . Eu achei que seria uma boa ideia montar isso temporariamente enquanto restaurava terabytes de arquivos.

Isso ajudou a acelerar a cópia marginalmente, mas não ajudou nos erros. Mais duas vezes, cheguei ao mesmo estado. Um ciclo de energia rígido é a única coisa que posso fazer, e depois, uma verificação de disco não mostra erros, os arquivos parecem bem, e eu posso copiar outros 100 GB.

O que está acontecendo? Eu acho que o disco em si é saudável. Eu não tive problemas com isso antes de reformatar. Devo fazer uma varredura setorial no disco? São 5 TB, então estou hesitante em fazer isso.

Eu restaurei mais alguns arquivos, observando os logs do kernel, como sugerido por Stephen Kitt. Antes de rsync falhar, comecei a ver alguns erros funky:

[ 8807.572286] ata4.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x6 frozen
[ 8807.572290] ata4.00: failed command: WRITE FPDMA QUEUED
[ 8807.572293] ata4.00: cmd 61/40:00:c0:57:b6/05:00:b7:00:00/40 tag 0 ncq 688128 out
[ 8807.572293]          res 40/00:00:00:4f:c2/00:00:00:00:00/40 Emask 0x4 (timeout)
[ 8807.572295] ata4.00: status: { DRDY }

As últimas três mensagens são repetidas várias vezes, então eu recebo:

[ 8807.572412] ata4: hard resetting link
[ 8808.060464] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 8808.062462] ata4.00: configured for UDMA/133
[ 8808.076459] ata4.00: device reported invalid CHS sector 0

A última mensagem se repete 20 vezes ou mais, e então eu recebo:

[ 8808.076526] ata4: EH complete

47 segundos depois, a sequência se repete. E novamente 81 segundos depois disso, e 120 segundos depois disso, exceto dessa vez, começa com:

[ 9160.779935] ata4.00: NCQ disabled due to excessive errors

Da próxima vez, é diferente. Começa o mesmo, mas então eu vejo:

[ 9235.819291] ata4: hard resetting link
[ 9241.181501] ata4: link is slow to respond, please be patient (ready=0)
[ 9245.839449] ata4: COMRESET failed (errno=-16)

Isso é repetido algumas vezes e, em seguida:

[ 9290.922301] ata4: limiting SATA link speed to 1.5 Gbps
[ 9290.922303] ata4: hard resetting link
[ 9295.948393] ata4: COMRESET failed (errno=-16)
[ 9295.948400] ata4: reset failed, giving up
[ 9295.948401] ata4.00: disabled

Existem alguns novos erros:

[ 9295.948522] sd 3:0:0:0: [sdf] FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 9295.948524] sd 3:0:0:0: [sdf] CDB: 
[ 9295.948525] Write(16): 8a 00 00 00 00 00 b9 0c fd 00 00 00 40 00 00 00
[ 9295.948538] blk_update_request: I/O error, dev sdf, sector 3104636160
[ 9295.948542] EXT4-fs warning (device sdf1): ext4_end_bio:317: I/O error -5 writing to inode 49807774 (offset 155189248 size 4194304 starting block 388079688)
[ 9295.948543] Buffer I/O error on device sdf1, logical block 388079264

(Note que eu embaralhei algumas unidades desde que comecei este post, e esta unidade agora é sdf em vez de sde.)

Este último erro é repetido várias vezes com blocos lógicos diferentes e, em seguida, recebo um número igual de vezes:

[ 9295.948585] EXT4-fs warning (device sdf1): ext4_end_bio:317: I/O error -5 writing to inode 49807774 (offset 155189248 size 4194304 starting block 388079856)

Há mais do mesmo, e o tempo todo a cópia continua sem reclamar. Finalmente eu recebo:

[ 9295.950321] Aborting journal on device sdf1-8.
[ 9295.950345] Buffer I/O error on dev sdf1, logical block 610304000, lost sync page write
[ 9295.950361] EXT4-fs (sdf1): Delayed block allocation failed for inode 49807775 at logical offset 0 with max blocks 1024 with error 30
[ 9295.950362] Buffer I/O error on dev sdf1, logical block 0, lost sync page write
[ 9295.950365] EXT4-fs (sdf1): This should not happen!! Data will be lost
[ 9295.950365] 
[ 9295.950366] EXT4-fs error (device sdf1) in ext4_writepages:2421: Journal has aborted
[ 9295.950368] EXT4-fs error (device sdf1): ext4_journal_check_start:56: Detected aborted journal
[ 9295.950370] JBD2: Error -5 detected when updating journal superblock for sdf1-8.
[ 9295.950371] EXT4-fs (sdf1): Remounting filesystem read-only
[ 9295.950372] EXT4-fs (sdf1): previous I/O error to superblock detected
[ 9295.950379] Buffer I/O error on dev sdf1, logical block 0, lost sync page write
[ 9295.950394] Buffer I/O error on dev sdf1, logical block 0, lost sync page write
[ 9326.009002] scsi_io_completion: 10 callbacks suppressed
[ 9326.009007] sd 3:0:0:0: [sdf] FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 9326.009009] sd 3:0:0:0: [sdf] CDB: 
[ 9326.009011] Write(16): 8a 00 00 00 00 00 00 00 0f b8 00 00 00 08 00 00
[ 9326.009018] blk_update_request: 10 callbacks suppressed
[ 9326.009020] blk_update_request: I/O error, dev sdf, sector 4024
[ 9326.009023] Buffer I/O error on dev sdf1, logical block 247, lost async page write

(Note que desta vez eu não desmontei e remontei com data = writeback, então ele estava fazendo o seu diário padrão).

Depois disso, o rsync falhou, presumivelmente porque o sistema de arquivos foi remontado como somente leitura.

Sinto muito pelo despejo de log. Eu tentei reduzi-lo ao essencial, mas tenho medo de não estar familiarizado o suficiente com o que está acontecendo aqui para reduzir ainda mais.

    
por P Daddy 31.03.2016 / 15:32

1 resposta

2

Isso parece um problema de hardware, em vez de um bug do kernel. Você pode tentar o seguinte:

  • reposicione o cabo SATA
  • use outro cabo SATA
  • executar o diagnóstico SMART (os autotestes, consulte smartmontools )
  • executar uma varredura badblocks destrutiva

Se você tiver uma unidade de reposição ou computador, você também pode tentar alternar (use outra unidade no mesmo computador, use a unidade problemática em outro computador) para verificar se a placa-mãe está com defeito. Como a unidade parece ter problemas sob carga, um simples dd if=/dev/zero of=... com parâmetros de tamanho apropriados pode ser suficiente para reproduzir os erros.

Não tenho certeza se a garantia da sua unidade se aplicaria, pois era originalmente uma unidade externa ...

    
por 31.03.2016 / 18:47