I was just experimenting with snapshots in LVM on Ubuntu 12.10. I created a snapshot logical volume of 6.5 GiB, and after making some changes to the origin decided to merge the snapshot back in to undo them. All seemed to be going well, but I noticed several LVM-related segfault messages in syslog.

Commands entered:

sudo lvcreate -L6.5G -n backup_snapshot -s /dev/mapper/vg0-backup
# made some miscellaneous writes
sudo lvconvert --merge /dev/vg0/backup_snapshot
sudo umount /snapshot/backup
sudo umount /backup
sudo lvchange -an /dev/vg0/backup
sudo lvchange -ay /dev/vg0/backup
sudo mount /backup

From syslog:

Apr 12 04:57:10 bournemouth kernel: [ 5260.813253] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:00:11 bournemouth kernel: [ 5441.841401] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:02:00 bournemouth kernel: [ 5551.438487] show_signal_msg: 48 callbacks suppressed
Apr 12 05:02:00 bournemouth kernel: [ 5551.438495] lvm[5813]: segfault at 28 ip 000000000047f319 sp 00007fff60873de0 error 4 in lvm[400000+d9000]
Apr 12 05:02:01 bournemouth kernel: [ 5552.458797] lvchange[6449]: segfault at 28 ip 000000000047f319 sp 00007fff935f4380 error 4 in lvm[400000+d9000]

I then unmounted the origin LV, made sure the snapshot no longer existed, and ran fsck.ext4 -f on it; it checked out OK that way. But I'm still worried about the segfaults. Is it possible my data got messed up in some way that fsck wouldn't catch? The volume I was experimenting with was a backup one, and all the filesystems I have backed up on it are still in working order, so I could just start over and back them up again. But on the other hand, I'd like to keep my incremental backup history. I'd just like reassurance that I can trust these backups.

2 Answers 2


Yeah it's definitely a bug but don't worry, LVM is smart enough to handle this stuff, I once had the power go out in the middle of a pvmove and all I had to do was basically get the server turned on again "cancel" the old pvmove and start it over it again.

First off, it's important to know that the tools you use are just a user-space interface to kernel processes. LVM lives inside the kernel so unless your kernel panic'd you're alright. The user space tools like pvmove or lvchange just interface with LVM for us and then just sit back and basically ask the kernel "Hey, you done with that yet? How'd it turn out?" or "Hey, how far along are we with this?" (Your specific issue is with lvchange segfaulting after lvchange successfully completes, sounds like a recently fixed bug so you may want to make sure you have all your system updates).

As a general point, you also shouldn't be so skiddish or paranoid about whether you're in trouble with LVM, it's designed to handle unexpected errors like this well (even when they impact it directly and not just the tool you're using) and that guarantee is part of the point of using a volume manager over traditional partitions. You're only in trouble if something really bad happens or you do something without thinking it through. LVM operates by extents (instead of blocks) and it doesn't make the copied extent active and the original inactive until the copy operation is already successfully completed. By doing so, half copied extents will stay marked as unallocated and any subsequent tools will jsut write over it. This is the case with my pvmove and with your lvchange.


Looking at this mailing list announcement, we can get a more detailed description of how your merge actually works "under the hood":

While the merging is active, any accesses to the origin device are [directed to] the snapshot that is being merged. When the merging finishes, the origin target is seamlessly reloaded and the merging snapshot is dropped. The [non-snapshot] filesystem can stay mounted during this time.

Figured it might be interesting to know

  • It was a tough decision, but I'm awarding you the answer because yours was more thorough. Commented Apr 15, 2013 at 21:02

While the heavy duty stuff is handled by the kernel (device mapper), your data as such should be safe. However, the LVM userland tools still have important functions; they keep the LVM metadata, the what's-stored-where-and-how, which the device mapper itself doesn't know nor care about.

If the LVM tool segfaults in the middle of updating such metadata, it is possible to suffer data loss. In a way, LVM is a filesystem for partitions; damaged LVM metadata would equal losing a filesystem superblock. That's why almost every change is logged/backed up to /etc/lvm/....

Segfaults are never good - if your LVM tools do this, you should stop using them and switch to a LVM version that works for you stable. And probably report a bug to your distribution, so the issue can be tracked down and fixed for good.

  • I have the 2.02.95-4ubuntu1.1 version of lvm2, which seems to be standard in Ubuntu 12.10. It looks like that's still the version that will be in 13.04, so I guess I'll compile the current latest (2.02.98) from source. Commented Apr 13, 2013 at 6:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .