erro de entrada / saída na partição ext3 limpa - como verificar o que há de errado com o bloco de dados

Question

Eu tenho um problema com um arquivo em uma partição ext3 no servidor CentOS 5 (versão do kernel 2.6.18-164.15.1.el5) com um controlador HP Raid:

hpacucli ctrl all show detail

Smart Array P410 in Slot 1
   Bus Interface: PCI
   ...

A ferramenta HP não reporta problemas.

É a partição normal ext3 com o tamanho do bloco definido para 2k, e está tudo bem - saída fsck:

fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

O inode do arquivo também está OK:

File: 'name.xxx'
Size: 3126962       Blocks: 6124       IO Block: 4096   regular file
Device: 6851h/26705d    Inode: 64579729    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2014-07-28 09:02:59.000000000 -0400
Modify: 2014-07-28 09:02:59.000000000 -0400
Change: 2014-07-28 09:02:59.000000000 -0400

Uma das operações que não posso executar é a cópia de arquivo:

> cp /long_path/name.xxx .
 cp: reading '/long_path.name.xxx': Input/output error

Para identificar onde está o problema eu corro o dd para copiar o arquivo:

> dd if=/long_path/name.xxx bs=2048 of=test
 dd: reading '/long_path/name.xxx': Input/output error
 222+0 records in
 222+0 records out
 454656 bytes (455 kB) copied, 0.042867 seconds, 10.6 MB/s

Então eu acho que esse problema está no bloco de 223 arquivos.

O Debugfs deve ajudar a localizar esse bloco no disco

debugfs  -R "stat name.xxx" /dev/sdf
debugfs 1.39 (29-May-2006)
Inode: 64579729   Type: regular    Mode:  0644   Flags: 0x0   Generation: 2900468317
User:     0   Group:     0   Size: 3126962
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 6124
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x53d64a03 -- Mon Jul 28 09:02:59 2014
atime: 0x53d64a03 -- Mon Jul 28 09:02:59 2014
mtime: 0x53d64a03 -- Mon Jul 28 09:02:59 2014
BLOCKS:
(0):130402311, (1-4):130402844-130402847, (5-6):130484033-130484034, (7):130484036,
(8-10):130484049-130484051, (11):130484055, (IND):130761221, (12-13):130761222-130761223,   
(14):130763791, (15):130763942, (16):130765268, (17-23):130838937-130838943,  
(24-46):130853946-130853968, (47-48):130855126-130855127, (49):130855215, 
(50-53):130856428-130856431, (54-104):130856533-130856583, (105-341):130856748-130856984, 
...
[MORE BLOCKS]     
....
TOTAL: 1531

Então eu acho que os dados problemáticos estão no bloco 130856866.

Como posso obter mais informações sobre esse bloco? Eu corri badblocks e tenho uma lista de blocos ruins. Meu palpite é que eu tenho que multiplicar acima do número do bloco por 2 (o tamanho do bloco do sistema de arquivos é 2K e os badblocks usam 1K por padrão). Também badblocks verifica um disco, não uma partição, então talvez eu deva adicionar algum offset (existe uma partição nesse disco, então provavelmente não).

> fdisk -l /dev/sdf

Disk /dev/sdf: 2000.3 GB, 2000365379584 bytes
255 heads, 63 sectors/track, 243197 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
       Device Boot      Start         End      Blocks   Id  System
/dev/cciss/c0d5p1   *       1      243197  1953479871   83  Linux

Eu também pensei em usar o smartd. O que devo procurar?

Error counter log:
       Errors Corrected by           Total   Correction     Gigabytes    Total
           ECC          rereads/    errors   algorithm      processed    uncorrected
       fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0     1457         0  2887405961          0      65948.712          18
write:         0        0         0         0          0      15056.493           0
verify:        0        1         0  361901613          0       3591.720           0

Non-medium error count:      226

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
   Description                              number   (hours)
# 1  Background long   Failed in segment -->       -   34479          16845361 [0x3 0x11 0x0]
# 2  Background short  Completed                   -      44                 - [-   -    -]
# 3  Background short  Completed                   -      39                 - [-   -    -]
# 4  Background long   Completed                   -       6                 - [-   -    -]

Long (extended) Self Test duration: 18500 seconds [308.3 minutes]

Background scan results log
Status: scan is active
  Accumulated power on time, hours:minutes 34541:56 [2072516 minutes]
  Number of background scans performed: 1139,  scan progress: 38.18%
  Number of background medium scans performed: 1139

 #  when        lba(hex)    [sk,asc,ascq]    reassign_status
 1 19215:06  0000000000014c61  [3,11,0]   Recovered via rewrite in-place
 2 19215:07  0000000000014c66  [3,11,0]   Recovered via rewrite in-place
 3 19413:28  0000000001010a31  [3,11,0]   Require Write or Reassign Blocks command
 4 19943:24  000000000001ea99  [3,11,0]   Recovered via rewrite in-place
 5 20152:23  00000000000232b8  [3,11,0]   Recovered via rewrite in-place
 6 31229:34  810000004087f984  [3,11,0]   Require Write or Reassign Blocks command
 7 33021:51  810000004087ba85  [3,11,0]   Require Write or Reassign Blocks command
 8 33021:51  000000004087ba9f  [3,11,0]   Require Write or Reassign Blocks command
 9 33021:52  000000004087bad6  [3,11,0]   Require Write or Reassign Blocks command
10 33029:43  000000004087baa5  [3,11,0]   Require Write or Reassign Blocks command
11 33055:27  000000004087bac3  [3,11,0]   Require Write or Reassign Blocks command
12 33244:40  810000004087f9d6  [3,11,0]   Require Write or Reassign Blocks command
13 33431:58  990000004087f105  [0,0,0]   Reassignment by disk failed
14 33480:17  00000000463d7713  [3,11,0]   Require Write or Reassign Blocks command
15 33480:19  00000000463d7723  [3,11,0]   Require Write or Reassign Blocks command
16 33480:20  00000000463d7725  [3,11,0]   Require Write or Reassign Blocks command
17 33480:28  81000000463d774e  [3,11,0]   Require Write or Reassign Blocks command
18 33686:17  8100000044e50edc  [3,11,0]   Require Write or Reassign Blocks command
19 34154:17  81000000432bef27  [3,11,0]   Require Write or Reassign Blocks command
20 34463:43  810000001f32decd  [3,11,0]   Require Write or Reassign Blocks command
21 34463:43  0000000030080000  [3,11,0]   Require Write or Reassign Blocks command

Como devo casar com a saída smartctl acima (ou qualquer outra saída do smartd run) com o meu problema inicial.

Esse problema também não deveria ser tratado pelo software HDD?

BTW. Eu encontrei o seguinte link útil para entender a saída 'debugs -R'. Talvez o link seja útil para mais uma pessoa.

UPDATE

Ao pesquisar mais, descobri que a ação relacionada a inodes problemáticos (como o comando cp acima) dispara a seguinte linha no log do kernel:

kernel: cciss: cmd ffff810037e00000 has CHECK CONDITION sense key = 0x3 

'sense key' é um 'status' e parte do padrão SCSI ( lista aqui e mais descrição < a href="http://www.adaptec.com/pt-br/support/scsi/2900/ava-2906/use_prod/scsi_event_codes.htm?nc=/en-us/support/scsi/2900/ava-2906 /use_prod/scsi_event_codes.htm">aqui ).

    

Answer 1

Então, para descobrir isso, fiz o seguinte.

Pegue seu número de bloco, multiplique por quatro e adicione um

(130856866 * 4) + 1 = 523427465

Isso representa o setor relatado como produzindo um erro de E / S. O tamanho do bloco sendo 2k, sendo os setores 512 bytes. O adicional extra é responsável pelo deslocamento do setor inicial para a partição.

Para correlacionar com o SMART, precisaremos converter o valor que agora temos em hexadecimal.

$ printf "0x%x\n" 523427465
0x1f32de89

Agora, quando você correlaciona isso com o que a SMART mostra, uma linha aparece suspeitamente próxima.

20 34463:43  810000001f32decd  [3,11,0]   Require Write or Reassign Blocks command

A que distância?

$ bc -l
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type 'warranty'. 
obase=16
ibase=16
1F32DECD-1F32DE89
44

Isso funciona como estando apenas entre 34816 e 32768 bytes de distância, mas não podemos dizer qual setor está danificado dos quatro que compõem o bloco.

Se eu tivesse que arriscar um palpite, eu diria que provavelmente há uma quantidade enorme de blocos em torno do mesmo endereço que reportará erros de E / S (supondo que a faixa do ataque seja de 32k ou qualquer outro).

Além disso, uma leitura pode não detectar o problema se o RAID estiver buscando o bloco em bloco de um disco diferente. Uma gravação deve propagar para todos os discos em uma configuração RAID1 de qualquer forma, para que isso possa fazer com que as gravações falhem, mas a leitura seja bem-sucedida. Além disso, se assumirmos que o tamanho do pedaço da placa RAID é de 32k, também podemos supor que o bloco danificado mais o relatado pela SMART esteja danificado pelo que aconteceu naquele disco. É apenas o teste SMART lido a partir do disco bom para o primeiro 32k e o disco ruim para os próximos 32k.

Os discos rígidos modernos mantêm 'setores de reserva' para substituir setores danificados como este por um novo setor. Como você está recebendo isso, e a mensagem Reassign by disk failed do smart, eu diria que um disco acabou.

Em termos de fazer algo sobre isso; isso é um pouco mais complicado. O endereçamento LBA é uma abstração contra o disco real embaixo. Você precisaria identificar qual disco está causando esse problema, falhar na matriz RAID e substituí-lo.

Em qualquer caso, você tem um disco danificado e deve procurar substituí-lo o mais rápido possível.

    

Answer 2

Isso é muito para processar ... Mas algumas coisas saltam para mim.

Sua versão do kernel é: 2.6.18-164.15.1.el5 - Isso coloca sua revisão do kernel no nível EL5.4, ou por volta de março de 2010 .

Eu tive problemas persistentes de estabilidade e corrupção do sistema de arquivos ext3 no EL5. As coisas não foram totalmente consertadas até meados de 2012. Na minha pior situação, eu estava trabalhando com uma empresa de infraestrutura de nuvem que nunca atualizava os kernels de seu release base. Então comecei a ver esses problemas em escala em milhares de servidores EL5.

Existe alguma chance de você atualizar seu sistema operacional / kernel / e2fsprogs, fsck e tentar novamente?

Além disso, se o kernel for por volta de 2010, o BIOS do seu sistema e o firmware do Smart Array P410 provavelmente estarão muito desatualizados. Qual servidor de modelo é esse?

Editar:

Seus erros de cciss CHECK_CONDITION são a oferta. Não há necessidade de lidar com o SMART neste momento. Execute o HP Array Diagnostic Utility e ele irá destilar as informações de erro em um relatório. De qualquer forma, eu realmente espero que este não seja um array RAID5.

Você pode postar a saída de hpacucli ctrl all show config detail ?

    

Answer 3

Os blocos que falharam de fato podem ser lidos no log do kernel, que você pode ler em algum lugar abaixo de /var/log (provavelmente /var/log/kernel.log ) ou da saída do comando dmesg .

Cuidado: o que você precisa não é o número do setor do disco, mas o número do bloco específico da partição e do sistema de arquivos. Kernels desde 2.4.x estão dizendo ambos no dmesg.

Dar uma -L flag para e2fsck pode dar essa lista de blocos para a lista de bad blocks do sistema de arquivos. Assim, as etapas corretas são as seguintes:

Primeiro, verifique a lista dos blocos ruins de um dmesg.

Em segundo lugar, coloque-os em um arquivo de texto simples, então

cat >badblockfile.txt
34252345
3452345
23452345

(ctrl / d)

e2fsck -f -y -C0 /dev/diskname -L badblockfile.txt

Se você não puder interpretar o dmesg, coloque as partes relevantes aqui como comentários ou como extensão de sua pergunta.

EXTENSÃO

Seu sistema de arquivos tem 2k blocos e inicia no primeiro setor do seu disco rígido (que possui 512 bytes de setores). Assim, a fórmula entre o filesystem-blocks (que poderia ser dado ao e2fsck) e o disk-block (que estão na saída do dmesg), se muito simples:

filesystem_block=(serctor_no-1)/4

Se você não tiver blocos no nível do sistema de arquivos nas suas mensagens, também poderá usar essa fórmula.

DICA ALTERNATIVA

Há também uma dica adicional: o e2fsck tem um sinalizador -c . Isso chama a ferramenta badblocks antes de uma verificação e marca os blocos ruins recém-descobertos como ruins. Como eu experimentei, na verdade não está bem, na maioria dos casos não pode encontrar todos os blocos ruins. Em seu lugar eu corri isso para o fim de semana (ou pelo menos para a noite) em um loop infinito:

while true; do e2fsck -f -y -C0 -c /dev/sdf;done