O LVM está relatando erros de E / S, mas o disco não relata problemas. Argh

Question

Eu comecei a ver erros relatados pelo LVM em determinados Volumes Lógicos (e pelo Xen ao tentar criar máquinas virtuais nesses LVs). Mas eu executei testes no disco e não consigo ver nenhum problema de hardware.

Estamos rodando uma caixa XEN / Linux (Debian Lenny) aqui, rodando um único disco SATA gerenciado com o LVM2. Ele está em funcionamento há mais de um ano, com as únicas grandes mudanças sendo recentes no apt-get upgrade do kernel.

# uname -a
Linux hostname 2.6.26-2-xen-amd64 #1 SMP Thu Sep 16 16:32:15 UTC 2010 x86_64 GNU/Linux

Os erros aparecem assim:

# vgck
/dev/dm-20: read failed after 0 of 4096 at 0: Input/output error

E quando tento iniciar a VM que usa esse LV para sua unidade C (é uma máquina virtual do Windows), a VM se recusa a iniciar e vejo isso no final do arquivo de log /var/log/xen/qemu-dm-*.log :

...
Register xen platform.
Done register platform.
raw_read(6:/dev/vgroup/newvm-cdrive, 0, 0x7fff02bca520, 512) [20971520] read failed -1 : 5 = Input/output error
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
raw_read(6:/dev/vgroup/newvm-cdrive, 0, 0x12dfff0, 512) [20971520] read failed -1 : 5 = Input/output error

Isso aconteceu primeiro em duas VMs cujo disco foi baseado em um instantâneo de uma terceira VM original. Eu nuked os 2 LVs e recriou-os (novamente por snapshotting LV mesma VM, original), e eles estão bem desde.

No entanto, hoje eu tentei criar uma nova VM. Eu capturei o mesmo LV da VM original ( lvcreate -L500M --snapshot --name newvm-cdrive /dev/vgroup/original-cdrive ) e criei a nova VM. Inicialmente funcionou, mas depois de desligar a VM uma vez, ela se recusa a iniciar novamente, com os erros mostrados acima.

Meu primeiro palpite óbvio seria problemas físicos com a unidade, mas o smartmon não informa nada:

# smartctl -t long /dev/sda
# [later]
# smartctl -l selftest /dev/sda
smartctl version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%         1         -
# 2  Short offline       Completed without error       00%         0         -

Além disso, não está recebendo erros de badblocks .

Eu tentei executar vgck e pvck :

# vgck vgroup -v
    Using volume group(s) on command line
    Finding volume group "vgroup"
  /dev/dm-20: read failed after 0 of 4096 at 0: Input/output error

# pvck /dev/sda2
  Found label on /dev/sda2, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=192512

Encontrei algumas referências a essa mensagem de erro ("read failed after 0 of 4096 at ...") nas Interwebs, mas nada que pareça se aplicar à minha situação.

Alguma idéia?

Atualização: Conforme solicitado, abaixo está a saída de lvdisplay e ls -l. Ficar sem espaço no COW é plausível. Como eu conto?

# lvdisplay /dev/vgroup/newvm-cdrive
  /dev/dm-20: read failed after 0 of 4096 at 0: Input/output error
  --- Logical volume ---
  LV Name                /dev/vgroup/newvm-cdrive
  VG Name                vgroup
  LV UUID                jiarxt-q2NO-SyIf-5FrW-I9iq-mNEQ-iwS4EH
  LV Write Access        read/write
  LV snapshot status     INACTIVE destination for /dev/vgroup/original-cdrive
  LV Status              available
  # open                 0
  LV Size                10.00 GB
  Current LE             2560
  COW-table size         200.00 MB
  COW-table LE           50
  Snapshot chunk size    4.00 KB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:20

# ls -l /dev/dm-20
brw-rw---- 1 root disk 254, 20 2010-10-11 15:02 /dev/dm-20

E aqui está o fdisk -l.

# fdisk -l /dev/sda

Disk /dev/sda: 160.0 GB, 160000000000 bytes
255 heads, 63 sectors/track, 19452 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000080

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          31      248976   83  Linux
/dev/sda2              32       19452   155999182+  8e  Linux LVM

    

Answer 1

Ok, acho que a resposta é que o espaço COW para o volume lógico está cheio.

Usando o comando 'lvs' (que acabei de descobrir), vejo ...

# lvs
/dev/dm-20: read failed after 0 of 4096 at 0: Input/output error
LV             VG      Attr   LSize   Origin          Snap%  Move Log Copy%  Convert
[...other LVs...]
newvm-cdrive   mrburns Swi-I-   2.00G original-cdrive 100.00
[...other LVs...]

O capital 'S' no início da coluna 'Attr' significa 'Instantâneo inválido'. (A minúscula 's' significaria instantâneo (válido).) E como você pode ver, o Snap% é 100, ou seja, é usado todo o seu espaço COW.

Irritante, lvdisplay não fornece essas informações e não informa que seu volume lógico de instantâneo é inválido. (Tudo o que diz é que o status do instantâneo é 'INACTIVE', o que eu tomei como significando 'não atualmente em uso'.) E o comando lvs não é amplamente divulgado. E a mensagem de erro ("Erro de entrada / saída") não é muito útil - na verdade, não havia nenhuma mensagens de log ou mensagens de erro que sugerissem que 'a captura instantânea está cheia'. (Versões posteriores do LVM2 escrevem mensagens para / var / log / messages quando o espaço está começando a encher, mas a versão no Debian Lenny não. Boo.)

E para agravar o problema, não há discussão sobre isso na internet (ou pelo menos, não que eu possa encontrar)!

Eu me perguntei por que os instantâneos COW não podem ser corrigidos apenas adicionando mais espaço ao LV (usando lvextend , mas, na verdade, o espaço COW será necessário não apenas quando você gravar no destino do instantâneo, mas < em> também quando você escreve na fonte de snapshot. Assim, uma vez que sua área COW é preenchida, qualquer gravação no LV de origem deve necessariamente tornar o snapshot LV inválido e não recuperável facilmente.

    

Answer 2

(Não é uma resposta direta, mas espero que seja usada por outras pessoas que estejam enfrentando 100% de snapshots completos que causam erros de entrada / saída)

Isso aconteceu comigo: meu instantâneo ficou 100% cheio, mas o sistema de arquivos dentro dele achava que tinha muito espaço, resultando em input/output de erros sempre que eu executava lvs ou qualquer outro comando LVM2.

No meu caso, a única opção é excluir o instantâneo com lvremove , mas não consegui porque desmontei o instantâneo com preguiça usando umount -l . Isso tornou muito difícil rastrear quais processos estavam usando o sistema de arquivos montado até recentemente.

Eu obtive sucesso obtendo os números maiores + menores de volume do volume lógico, por exemplo, 252:10 no seguinte:

root@hostname:~# lvdisplay

  --- Logical volume ---
  LV Path                /dev/vg00/
  LV Name                snapshot_of_my_origin
  VG Name                vg00
  LV UUID                CWZxOa-depw-k5P4-SqDo-bdFb-h3Np-ukQkmM
  LV Write Access        read/write
  LV Creation host, time cz3328jlkj, 2016-07-12 13:47:31 +0100
  LV snapshot status     active destination for my_origin
  LV Status              available
  # open                 1
  LV Size                150.00 GiB
  Current LE             38400
  COW-table size         50.00 GiB
  COW-table LE           12800
  Allocated to snapshot  0.03%
  Snapshot chunk size    4.00 KiB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:10

Se você executar lsof como root, sem argumentos, você obterá uma lista completa dos arquivos abertos no sistema. Filtre por seus números maiores + menores de dispositivos de bloco, separados por uma vírgula , não dois pontos como acima, e você pode encontrar o processo usando:

root@hostname:~# lsof | sed -ne '1p; / 252,10 /p'
COMMAND     PID   TID       USER   FD      TYPE             DEVICE  SIZE/OFF       NODE NAME
bash       2055           upr473  cwd       DIR             252,10      4096          2 /

Observe que NAME é / , porque foi desmontado preguiçosamente, lsof não pode resolver seu nome de caminho original.

Mate este processo, 2055 neste exemplo, e tente lvremove et al novamente.