Corrupção surpreendente e fsck sem fim depois de redimensionar um sistema de arquivos

2

O sistema em questão tem o Debian Lenny instalado, rodando um kernel 2.6.27.38. O sistema tem memória de 16Gb e unidades 8x1Tb funcionando atrás de uma placa RAID de 3Ware.

O armazenamento é gerenciado via LVM e é composto exclusivamente de sistemas de arquivos ext3.

Versão resumida:

  • Execução de um convidado do KVM que tinha armazenamento de 1.7 TB alocado para ele.
  • O convidado estava atingindo um disco inteiro.
  • Decidimos, então, redimensionar o disco que estava sendo executado em

Estamos bastante familiarizados com o LVM e o KVM, por isso achamos que seria uma operação simples:

  • Pare o convidado do KVM.
  • Estenda o tamanho da partição LVM: "lvextend -L + 500Gb ..."
  • Verifique o sistema de arquivos: "e2fsck -f / dev / mapper /..."
  • Redimensione o sistema de arquivos: "resize2fs / dev / mapper /"
  • Inicie o convidado.

O convidado inicializou com sucesso, e a execução de "df" mostrou o espaço extra, no entanto, pouco tempo depois, o sistema decidiu remontar o sistema de arquivos somente leitura, sem qualquer indicação explícita de erro.

Sendo paranóico, desligamos o guest e executamos novamente a checagem do sistema de arquivos, dado o novo tamanho do sistema de arquivos que esperávamos que demorasse, entretanto ele agora está rodando para o > 24 horas e não há indicação de quanto tempo levará.

Usando strace eu posso ver que o fsck está "fazendo coisas", similarmente rodando "vmstat 1" Eu posso ver que existem muitas operações de entrada / saída de bloco ocorrendo.

Agora, minha pergunta é tripla:

  • Alguém se deparou com uma situação semelhante? Geralmente nós fizemos esse tipo de redimensionamento no passado com zero problemas.

  • Qual é a causa mais provável? (Cartão 3Ware mostra as matrizes RAID das lojas de apoio como sendo A-OK, o sistema host não foi reinicializado e nada no dmesg parece importante / incomum)

  • Ignorando btrfs + ext3 (sem maturidade suficiente para confiar) devemos fazer nossas partições maiores em um sistema de arquivos diferente no futuro para evitar essa corrupção (seja qual for a causa) ou reduzir o tempo de fsck? xfs parece o candidato óbvio?

por Steve Kemp 24.10.2010 / 11:31

3 respostas

4

Parece que volumes maiores que 1Tb têm problemas com o virtio:

link

link

link

    
por 13.05.2010 / 16:03
1

Neste caso, é provavelmente o virtio e o problema de 1 TB.

Mas, para mim, enfrentei problemas semelhantes ao acessar alternadamente um dispositivo fora de uma máquina virtual (incluindo o desligamento desta máquina) e dentro da máquina virtual. Se você acessar o dispositivo de bloco dentro da máquina virtual com acesso direto (por exemplo, em kvm config), isso significa sem cache / buffers e fora com buffers, você pode obter o seguinte problema:

  • redimensione o dispositivo fora de vm, o cache / buffers são preenchidos no host kvm.

  • inicie vm, reconheça problemas (outros!) e encerre.

  • dispositivo fsck.

Se tudo foi muito ruim, você leu a data do cache, mas isso foi alterado dentro da máquina virtual anteriormente executada, que acessou o dispositivo sem buffers / cache!

Eu também faço muitos redimensionamentos ext3 (desde 2.6.18) e faço isso o tempo todo ONLINE! AFAIK usa as funções do kernel para redimensionar, enquanto o redimensionamento offline usa o código da terra do usuário.

    
por 14.05.2010 / 13:11
1

Verifique também suas configurações de cache do KVM; O KVM não pode fazer cache, ler cache, write-back e gravar em cache, o que pode levar você de surpresa.

    
por 24.10.2010 / 12:43