Depois do travamento, o e2fsck falha com números / tamanhos de blocos estranhamente altos

Question

Após uma viagem demolidora, um Raspberry Pi meu começou a interromper o processo com o kernel panic (a mesma mensagem que aqui ) . Este é um Raspberry Pi rodando Raspbian, então ele roda de um cartão SD, de uma partição principal ext4 , que eu tentei reparar no meu PC com:

sudo e2fsck -f -y -v /dev/sdx2

No entanto, isso eventualmente falha com alguma saída estranha:

Error writing block 137439060017 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Error reading block 183472412950529 (Invalid argument).  Ignore error? yes
Force rewrite? yes
Error writing block 183472412950529 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Inode 13329, i_size is 4096, should be 549755817984.  Fix? yes
Inode 13607, i_size is 69632, should be 137439023104.  Fix? yes
Error reading block 36983963385857 (Invalid argument).  Ignore error? yes
Force rewrite? yes
Error writing block 36983963385857 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Error reading block 179632729097217 (Invalid argument).  Ignore error? yes
Force rewrite? yes
Error writing block 179632729097217 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Error reading block 17592186080054 (Invalid argument) while reading directory block.  Ignore error? yes
Force rewrite? yes
Error writing block 17592186080054 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Error storing directory block information (inode=17449, block=0, num=134507168): Memory allocation failed
/dev/sdx2: ***** FILE SYSTEM WAS MODIFIED *****
e2fsck: aborted
/dev/sdx2: ***** FILE SYSTEM WAS MODIFIED *****

Há duas coisas que estão preocupando aqui:

• os tamanhos de inode e de bloco, que parecem ridiculamente altos (estamos falando de um cartão SD de 16GB),
• e2fsck termina com Memory allocation failed - em um PC com 32 GB de RAM, a maioria dos quais é gratuita. Na verdade, ele ocupa a RAM livre antes de falhar.

Eu tentei configurar um diretório de arquivos de rascunho com o mesmo resultado ( e2fsck escreve alguns arquivos lá, e o diretório de destino está em uma montagem com + 250GB de espaço livre - ocupa a RAM disponível e falha) .

Parece que há algum dano nos parâmetros fundamentais do sistema de arquivos na partição afetada. Como diagnosticar e eliminar isso?

    

Answer 1

Eu dei uma rápida olhada no e2fsck source , e parece-me que existem lugares onde o erro " Memory allocation failed " pode ocorrer por razões que podem não ser erros de alocação de memória.

A string de erro é definida em [src]/lib/ext2fs/ext2_err.et.in em relação à constante EXT2_ET_NO_MEMORY . Isso pode ser retornado de vários locais no código em [src]/e2fsck/ . Aqui está um exemplo de ea_refcount.c :

errcode_t ea_refcount_increment(ext2_refcount_t refcount, blk_t blk, int *ret)
{
    struct ea_refcount_el   *el;

    el = get_refcount_el(refcount, blk, 1);
    if (!el)
        return EXT2_ET_NO_MEMORY; 

get_refcount_el() está no mesmo arquivo:

static struct ea_refcount_el *get_refcount_el(ext2_refcount_t refcount,
                          blk_t blk, int create)
{
    int low, high, mid;

    if (!refcount || !refcount->list)
        return 0;    

Esse não é o único motivo pelo qual ele retornará null, nem a única razão que parece não estar diretamente relacionada a uma alocação com falha.

Para realmente provar que eu teria que fazer mais escavações, mas isso se encaixa com a sua afirmação de que realmente não esgotou a memória do sistema.

Sendo este o caso, talvez o problema esteja relacionado a um potencial obscuro e imprevisível de controladores de cartão SD perturbados / danificados, mas ainda assim é um bug no e2fsck na medida em que algum tipo de verificação de sanidade ou algo deve ser feito para pegar isso, mesmo que seja apenas para dizer: "Desculpe, seu dispositivo está ferrado" (provavelmente verdadeiro) versus "Sem memória" (provavelmente não é verdade). Você pode relatar isso ( "Em caso de erros nesses programas, entre em contato com Ted Ts'o em [email protected] ou [email protected]" - Acredito que TT é um dev de kernel do linux), e você pode referenciar este Q & A.

Além disso, você também pode esquecer o que está nessa placa e fazer um teste destrutivo de leitura / gravação:

badblocks -v -w -b 1048576 -c 16 /dev/sdx

Lembre-se de que é um teste DESTRUTIVO - você perderá todos os seus dados. Badblocks não é útil para criar uma lista de badblocks reais para um cartão SD (eles não informam endereços físicos reais por causa do nivelamento de desgaste), mas se o cartão estiver borked, ele provavelmente o informará. Testar um cartão de 16 GB leva menos de uma hora.

    

Answer 2

Quando você executa o e2fsck -fy, você realmente precisa salvar toda a transcrição do e2fsck, e não apenas mostrar as últimas duas mensagens de erro. Pode ser que o sistema de arquivos tenha sido muito danificado e a opção -y significa continuar, não importa o que aconteça.

Parece que os descritores de grupos de blocos foram mal corrompidos, de modo que os locais da tabela de inodes eram insanos. O E2fsck provavelmente tentou repará-lo, mas por algum motivo ele não conseguiu consertá-lo, e "-y" significa que continuará funcionando apesar disso. Então, quando as pessoas enviam relatórios de bugs, eu sempre sugiro que eles enviem a transcrição completa do e2fsck, e não apenas os últimos erros.