LVM2 en snapshots => I/O errors

[lckarssen]

Ik heb delen van het bestandssysteem van mijn (Slackware 10.1) servertje op LVM2 volumes geplaatst, o.a. vanwege het gemak bij het resizen in de toekomst, maar ook om consistente backups te kunnen maken d.m.v. snapshots.

Het probleem dat ik tegenkom is dat ik I/O fouten krijg als ik van de snapshot lees. ls -l gaat zonder problemen, maar bijvoorbeeld de inhoud van een bestand lezen geeft I/O errors.
Volgens http://sources.redhat.com/dm/patches.html zit het snapshot target inmiddels in de kernel (dat klopt, ik heb 'm immers geselecteerd), dus dat zou het probleem niet moeten zijn (een google zoektochtje op LVM2 snapshot problemen levert meestal hits van vroege 2.6 kernels waarin nog geen snapshotsupport zit). Ik gebruik kernel 2.6.11.8.

Een voorbeeldje van hoe ik mijn snapshots maak en gebruik:

code:

root@jerom:~# lvcreate -L1G -s -nsnap /dev/raidvg/tmp 
  Logical volume "snap" created
root@jerom:~# mount /dev/raidvg/snap /mnt/hd/
root@jerom:~# ls -lh /mnt/hd/*bz2
-rw-r--r--  1 root root 458K 2005-05-06 17:59 /mnt/hd/squirrelmail-1.4.4.tar.bz2
-rw-r--r--  1 root root 5.5M 2005-05-06 17:13 /mnt/hd/tikiwiki-1.8.5.tar.bz2
root@jerom:~# cp /mnt/hd/*bz2 .
cp: reading `/mnt/hd/squirrelmail-1.4.4.tar.bz2': Input/output error
cp: reading `/mnt/hd/tikiwiki-1.8.5.tar.bz2': Input/output error
root@jerom:~# umount /mnt/hd/
root@jerom:~# lvremove -f /dev/raidvg/snap
  Logical volume "snap" successfully removed

root@jerom:~# cp /tmp/*bz2 .              
root@jerom:~# ls -lh *.bz2
-rw-r--r--  1 root root 458K 2005-05-17 18:56 squirrelmail-1.4.4.tar.bz2
-rw-r--r--  1 root root 5.5M 2005-05-17 18:56 tikiwiki-1.8.5.tar.bz2

Uit de laatste regels blijkt dat kopieren vanaf de originele locatie wel lukt. Waarom vanaf de snapshot niet??

[Jelmer]

Zou je iets meer info willen geven? Type filesystem, mount opties & hoeveelheid I/O fs dat snapshot is, lvm lvs, lvm vgs, lvm pvs

[lckarssen]

Op alle LVs staat het Ext3 fs. Het is een servertje thuis waarop en webserver en ongeveer 5 mailaccounts draaien. Weinig IO dus.
Dit is het relevante deel van /etc/fstab:

code:

/dev/raidvg/home /home            ext3        defaults,grpquota,usrquota  0   2
/dev/raidvg/tmp  /tmp             ext3        defaults         0   2
/dev/raidvg/var  /var             ext3        defaults         0   2
/dev/raidvg/music /var/music      ext3        defaults         0   2
/dev/raidvg/sysadm /var/sysadm    ext3        defaults         0   2
/dev/raidvg/sharedtmp /var/sharedtmp ext3     defaults         0   2
/dev/nonraidvg/video  /var/video  ext3        defaults         0   2
/dev/nonraidvg/backups /var/sysadm/backups ext3 defaults       0   2

De VG 'raidvg' draait op een RAID1 array (/dev/md2) verspreid over twee 160GB SATA disks, de VG 'nonraidvg' draait op een 160GB ATA133 disk, deze VG bestaat uit verschillende partities van elk ca. 20GB.

Output vgdisplay:

code:

root@jerom:~# vgdisplay
  --- Volume group ---
  VG Name               nonraidvg
  System ID             
  Format                lvm2
  Metadata Areas        6
  Metadata Sequence No  9
  VG Access             read/write
  VG Status             resizable
  MAX LV                255
  Cur LV                2
  Open LV               2
  Max PV                255
  Cur PV                6
  Act PV                6
  VG Size               111.82 GB
  PE Size               4.00 MB
  Total PE              28626
  Alloc PE / Size       15360 / 60.00 GB
  Free  PE / Size       13266 / 51.82 GB
  VG UUID               cPli89-g7X7-1FhB-OJZn-sJ5n-HG1o-snxVm8
   
  --- Volume group ---
  VG Name               raidvg
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  55
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                7
  Open LV               6
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               143.30 GB
  PE Size               4.00 MB
  Total PE              36685
  Alloc PE / Size       13824 / 54.00 GB
  Free  PE / Size       22861 / 89.30 GB
  VG UUID               f7MV0u-Nsy5-cqJO-rdBz-2py0-SLRQ-aKAvhC

De LV's zijn tussen de 2 en de 20GB groot. Eventueel kan ik ook de output van lvdisplay en pvdisplay posten.

Dit is de output van lvdisplay voor een snaphsot:

code:

root@jerom:~# lvcreate -L1G -s -nsnap /dev/raidvg/tmp
  Logical volume "snap" created
root@jerom:~# lvdisplay /dev/raidvg/snap 
  --- Logical volume ---
  LV Name                /dev/raidvg/snap
  VG Name                raidvg
  LV UUID                UVKBkt-8EoG-mahR-GrQA-bX4E-bgJ1-gquPQG
  LV Write Access        read/write
  LV snapshot status     active destination for /dev/raidvg/tmp
  LV Status              available
  # open                 0
  LV Size                2.00 GB
  Current LE             512
  Segments               1
  Snapshot chunk size    8.00 KB
  Allocated to snapshot  0.00% 
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:11

Output lvm commandos (inclusief 1 snapshot):

code:

root@jerom:~# lvm vgs
  VG        #PV #LV #SN Attr  VSize   VFree 
  nonraidvg   6   2   0 wz--n 111.82G 51.82G
  raidvg      1   8   1 wz--n 143.30G 88.30G
root@jerom:~# lvm lvs
  LV        VG        Attr   LSize  Origin Snap%  Move Copy% 
  backups   nonraidvg -wi-ao 30.00G                          
  video     nonraidvg -wi-ao 30.00G                          
  home      raidvg    -wi-ao 20.00G                          
  music     raidvg    -wi-ao 10.00G                          
  sharedtmp raidvg    -wi-ao  5.00G                          
  snap      raidvg    swi-a-  1.00G tmp      0.00            
  sysadm    raidvg    -wi-ao  5.00G                          
  tmp       raidvg    owi-ao  2.00G                          
  usrlocal  raidvg    -wi-a-  2.00G                          
  var       raidvg    -wi-ao 10.00G                          
root@jerom:~# lvm pvs
  PV         VG        Fmt  Attr PSize   PFree 
  /dev/hda10 nonraidvg lvm2 a-    18.64G 18.64G
  /dev/hda11           lvm2 --    18.64G 18.64G
  /dev/hda12           lvm2 --    21.24G 21.24G
  /dev/hda5  nonraidvg lvm2 a-    18.64G     0 
  /dev/hda6  nonraidvg lvm2 a-    18.64G     0 
  /dev/hda7  nonraidvg lvm2 a-    18.64G     0 
  /dev/hda8  nonraidvg lvm2 a-    18.64G 14.55G
  /dev/hda9  nonraidvg lvm2 a-    18.64G 18.64G
  /dev/md2   raidvg    lvm2 a-   143.30G 88.30G

[lckarssen]

Vreemd, toen ik na het uitvoeren van de commando's in mijn vorige post bestanden van een snapshot (zowel uit raidvg als uit nonraidvg) wilde kopieren liep alles naar behoren...

Doet lvm vgs/lvs/pvs nog iets anders behalve listen van de gegevens?

[lckarssen]

Na een reboot vanochtend weer geprobeerd te kopieren van snapshots.
Dit zijn de resultaten:
- Bij sommige LVs gaat het goed, bij sommige fout.
- Onafhankelijk van het gebruik van de lvm commando's, dus daar zal het wel niet aan liggen.
- Onafhankelijk van welke VG ik gebruik.
- Het blijkt bestandsafhankelijk te zijn. Sommige bestanden op een snapshot kan ik wel lezen, sommige niet. Het gaat niet steeds om dezelfde bestanden. Zoals mijn vorige post blijkt is het soms wel en soms niet mogelijk om een bepaald bestand te kopieren.
- Als een bestand wel of geen I/O error geeft, geldt dat voor de duur van de snapshot.
- Read-only mounten van de snapshot geeft geen verschil.

Elke input is welkom.

[lckarssen]

We komen verder: Zodra ik van de snapshot probeer te lezen krijg ik het volgende te zien in /var/log/messages:

code:

May 19 13:21:55 jerom kernel: attempt to access beyond end of device
May 19 13:21:55 jerom kernel: dm-11: rw=0, want=2705161720, limit=4194304

En dat enkele keren herhaald voor verschillende want= waarden.
Blijkbaar is er iets mis met (Slackware's) device mapper.
lvcreate geeft (/var/log/messages)

code:

May 19 13:18:45 jerom udev[9639]: configured rule in '/etc/udev/rules.d/udev.rules' at line 38 applied, 'dm-9' is ignored
May 19 13:18:45 jerom udev[9642]: removing device node '/dev/dm-9'
May 19 13:18:45 jerom udev[9650]: configured rule in '/etc/udev/rules.d/udev.rules' at line 38 applied, 'dm-9' is ignored
May 19 13:18:45 jerom udev[9656]: configured rule in '/etc/udev/rules.d/udev.rules' at line 38 applied, 'dm-10' is ignored
May 19 13:18:45 jerom udev[9664]: configured rule in '/etc/udev/rules.d/udev.rules' at line 38 applied, 'dm-11' is ignored

Dat de udev de regels ignored klopt met wat in /etc/udev/rules.d/udev.rules staat (regel 37-42):

code:

# dm devices (ignore them)
KERNEL="dm-[0-9]*",     NAME=""
# create a symlink named after the device map name
# note devmap_name comes with extras/multipath
#KERNEL="dm-[0-9]*",     PROGRAM="/etc/udev/scripts/devmap_name %M %m", NAME="%k", SYMLINK="%c"
KERNEL="device-mapper", NAME="mapper/control"

Zou het uncommenten van de tweede "dm-[0-9]*" regel helpen?
De vraag is of deze melding iets met het probleem te maken hebben. Volgens mij gaat het hier gewoon om naamgeving. De devices zijn niet als /dev/dm? te benaderen, maar wel als /dev/mapper/raidvg-tmp etc.

lvremove van de snapshot geeft netjes (/var/log/messages):

code:

May 19 13:24:48 jerom udev[9740]: removing device node '/dev/dm-11'
May 19 13:24:48 jerom udev[9742]: removing device node '/dev/dm-10'
May 19 13:24:48 jerom udev[9748]: removing device node '/dev/dm-9'

Het begint me hier wel heet te worden. Ik krijg het vermoeden dat bestanden die geschreven worden gedurende de tijd dat hun filesysteem "gesnapshot" was, beschadigd raken. Blijkbaar gaat het schrijven naar het origineel van een gesnapshot volume niet goed...