Was ein Murks: Einer meiner Server brauchte dank Problem des Festplattentreibers einen Neustart. Nach dem Boot fiel mir auf, dass im LVM-System einige alte Snapshots von Systemtests liegen geblieben sind. Schnell mal aufräumen – oder auch nicht, denn dummerweise wollte LVM da nicht mitspielen. Erst mal eine kleine Übersicht des Systems:
root@rescue:~# pvs
PV VG Fmt Attr PSize PFree
/dev/md2 storage lvm2 a-- 2.70t 1.57t
root@rescue:~# vgs
VG #PV #LV #SN Attr VSize VFree
storage 1 32 9 wz--n- 2.70t 1.57t
root@rescue:~# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
[...]
test-www4-boot storage swi-a-s- 512.00m www4-boot 0.10
test-www4-data storage swi-a-s- 70.00g www4-data 38.39
test-www4-root storage swi-a-s- 20.00g www4-root 63.09
test2-www4-boot storage swi-a-s- 512.00m www4-boot 0.10
test2-www4-data storage swi-a-s- 70.00g www4-data 37.31
test2-www4-root storage swi-a-s- 20.00g www4-root 59.58
www4-boot storage owi-a-s- 512.00m
www4-data storage owi-a-s- 73.24g
www4-root storage owi-a-s- 20.00g
[...]
Man sieht die mit „test“ beginnenden Snapshots welche entfernt werden sollen. Üblicherweise reicht hier ein lvremove welches folgende Ausgabe brachte:
Do you really want to remove active logical volume test-www4-root? [y/n]: y
/sbin/dmeventd: stat failed: No such file or directory
/sbin/dmeventd: stat failed: No such file or directory
Unable to deactivate open storage-test--www4--root-cow (253:2)
Failed to resume test-www4-root.
libdevmapper exiting with 3 device(s) still suspended.
Ab diesem Punkt ist die LVM-Verwaltung faktisch tot. Kommandos wie z.B. lvs hängen sich auf und geben keine Ausgabe. Erst nach einem Reboot ist die Verwaltung wieder möglich, dann taucht der soeben gelöschte test-www4-root wieder auf, ist allerdings kein Snapshot mehr und lässt sich nun auch fehlerfrei entfernen. Keine schöne Lösung, denn ich habe viele Snapshots und dazu eine Abneigung gegen Reboots. Mit strace findet man im hängenden Zustand folgendes:
ioctl(3, DM_TABLE_STATUS, 0x81b5a40) = 0
stat64("/dev/storage/www4-root", {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_DIRECT|O_LARGEFILE|O_NOATIME) = 4
fstat64(4, {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_LARGEFILE) = 5
ioctl(5, BLKGETSIZE64, 0xffcc33a8) = 0
close(5) = 0
close(4) = 0
open("/dev/storage/www4-root", O_RDONLY|O_LARGEFILE) = 4
ioctl(4, BLKGETSIZE64, 0xffcc3378) = 0
close(4) = 0
stat64("/dev/storage/www4-root", {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_DIRECT|O_LARGEFILE|O_NOATIME) = 4
fstat64(4, {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
ioctl(4, BLKBSZGET, 0x8174458) = 0
_llseek(4, 21474770944, [21474770944], SEEK_SET) = 0
read(4,
Der Auslöser scheint also die Snapshotquelle zu sein, nicht der Snapshot selbst. Eine Suche brachte mich zur Debian-ML auf der das Problem beschieben wird – dankenswerterweise funktionierte der Workarround auch in meiner Situation:
– Der lvremove-Befehl wird in einer Shell abgesetzt und hängt sich auf
– Auf einer zweiten Shell setzt man die Snapshotquelle manuell mit folgenden Befehl wieder in Gang: „dmsetup resume /dev/storage/www4.root“
– Die erste Shell reagiert wieder, der Snapshot sollte verschwunden sein
– Ggf. zurückgebliebene Laufwerksleichen werden mit „dmsetup remove /dev/storage/xxx“ entfernt