ext4: redimensionamento online não detectado

2

Em um servidor RedHat 6, encontramos um problema com o redimensionamento online de um sistema de arquivos ext4.

Com apenas / dev / sda, nós tínhamos 13 GB disponíveis no grupo de volume, mas precisávamos de 20 GB a mais em um volume lógico de 36 GB. Adicionado / dev / sdb ao grupo de volumes, e o sistema de arquivos foi estendido (lvextend) e redimensionado (resize2fs) para 56GB. Nenhuma mensagem de erro durante o redimensionamento e o sistema operacional relatou o novo tamanho.

O volume lógico em questão hospeda uma instalação do IBM HTTP Server (apache 2.2), arquivos de configuração e de log para alguns servidores da Web diferentes.

Esta manhã, o uso do sistema de arquivos cresceu além de 36 GB. O que aconteceu primeiro foi que os servidores da Web pararam de registrar (descobertos depois), enquanto os servidores da Web continuavam funcionando sem problemas. 2,5 horas depois, em relação à rotação de logs e algumas outras gravações no sistema de arquivos, as coisas começaram a congelar. Significado: os servidores da Web pararam de receber tráfego, embora os processos permanecessem ativos, tentando "impedir" que um arquivo de log fosse interrompido e não pudesse ser interrompido. A carga do servidor passou de 0,10 para 4000 (sim ...) - principalmente relacionada ao iowait (parece).

O sollution era desligar o servidor web - kill -9 era o único caminho, e reinicializava o servidor. Umount o sistema de arquivos, fez um fsck (sem erros) e inicie as coisas novamente. Sem problemas desde.

Podemos calcular com exatidão o erro com o log parando no momento em que o uso do disco (lv) cresceu acima do tamanho anterior de 36 GB.

Os serviços em outros sistemas de arquivos parecem funcionar bem - entre outros, o sistema operacional.

Em / var / log / messages vimos, por exemplo:

kernel: INFO: task httpd:<pid> blocked for more than 120 seconds.
kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kernel: httpd         D 0000000000000001     0  6889   6865 0x00000080
kernel: ffff88023aa99c88 0000000000000086 0000000000000000 0000000000006102
kernel: ffff88010aebaa80 ffff880105dd0ae0 000000003aa99c08 ffff880105dd0ae0
kernel: ffff880105dd1098 ffff88023aa99fd8 000000000000fb88 ffff880105dd1098
kernel: Call Trace:
kernel: [<ffffffff8150efbe>] __mutex_lock_slowpath+0x13e/0x180
kernel: [<ffffffff8150ee5b>] mutex_lock+0x2b/0x50
kernel: [<ffffffff8111c461>] generic_file_aio_write+0x71/0x100
kernel: [<ffffffffa0097fb1>] ext4_file_write+0x61/0x1e0 [ext4]
kernel: [<ffffffff81180d7a>] do_sync_write+0xfa/0x140
kernel: [<ffffffff81096ca0>] ? autoremove_wake_function+0x0/0x40
kernel: [<ffffffff8121bc06>] ? security_file_permission+0x16/0x20
kernel: [<ffffffff81181078>] vfs_write+0xb8/0x1a0
kernel: [<ffffffff81181971>] sys_write+0x51/0x90
kernel: [<ffffffff810dc645>] ? __audit_syscall_exit+0x265/0x290
kernel: [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b

Versões:

Kernel: 2.6.32-358.2.1.el6.x86_64
lvm2-2.02.98-9.el6.x86_64
e2fsprogs-1.41.12-14.el6.x86_64

Não foram encontrados problemas com o hardware subjacente.

    
por sastorsl 12.06.2013 / 00:39

1 resposta

1

A resposta é: O sistema de arquivos foi criado com mke2fs <device>

O comportamento padrão é criar um sistema de arquivos ext2. No entanto, ele foi montado como um sistema de arquivos ext4 - sem nenhuma mensagem de erro - e posteriormente percebido como um sistema de arquivos ext4.

Portanto, não é de se estranhar que o redimensionamento on-line tenha funcionado, e não admira que a parte estendida tenha sido reconhecida após uma desmontagem / montagem ou reinicialização.

Demorou algum tempo para descobrir, já que havia muito tempo entre a criação e o redimensionamento e foi finalmente descoberto ao executar blkid , que dizia "ext2". tune2fs -l também disse "não limpa".

    
por 14.06.2013 / 20:30