Parece que volumes maiores que 1Tb têm problemas com o virtio:
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:
Estamos bastante familiarizados com o LVM e o KVM, por isso achamos que seria uma operação simples:
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?
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.
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.