[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#419209: lvm2: Hangs during snapshot creation

severity 419209 important

On Wed, Mar 04, 2009 at 10:44:28AM +0100, Klaus Ethgen wrote:
> first of all, I raised the severity of the bug to critical as it makes
> the whole system break.

lvm2 manages blockdevices via the device-mapper framework, so it manages
the system. It is the purpose of this tool and it will not hold you from
doing stupid things.

And for now I consider taking snapshots of / or /var as stupid, because
it is impossible to recover if something goes wrong. And without a
working filesystem on this locations, the system will just block. It may
work, but it also may break horrible as the kernel interface does not
allow to do this change atomic.

>                         Also I add debian-devel to Cc as the bug is very
> problematic and I wonder how lvm2 was able to get into lenny with that
> big problem!

We have many software who only works for most but not for all people.

> Also I am willing to help solving the bug. My next step will be to
> import the whole version history to git and try to besect the problem.

Why do you think this would be a problem of the userspace part?

> So this bug is a complete show stopper for lenny!!!!

If you want to help you can provide the following information when it
goes wrong:
- "uname -a"
- "dmesg"
- "dmsetup table"
- "cat /proc/mounts"
- debug log of the "lvcreate -s" call, using -vvvv
- your snapshot creation script

> Am Sa den 14. Apr 2007 um 12:53 schrieb Jean-Luc Coulon (f5ibh):
> > New lvm2 version (2.02.24) hangs during snapshot creation.
> > The lvmvreate process is not killeable at this point and the system need to be
> > reboted.
> That is the correct description.

There was a bug in older kernels which blocked on devmapper table
reload, however I've only seen this with the mirror target during a
pvmove call.

>                                  But more over the system will be
> unbootable at all! I have to run /etc/init.d/reboot stop by hand to hard
> reboot the system. A normal shutdown will end in a hanging system with
> no remote access at all. The only solution at that point is to
> powercycle the machine which is very problematic with remote system.

This is the normal behaviour if you lock out either a filesystem or have
some parts of the kernel disfunctional after oopses.

> Am Fr den  2. Nov 2007 um 16:21 schrieb Stefan Pfetzing:
> > did you try to snapshot your /var? Because to me it seemms like the  
> > current lvm2 configurations tries to use /var/lock/lvm for its locking 
> > files, and this leads to a deadlock.
> This is not really a problem as it is irrelevant if that file is locked
> or not in the sapshoot.

It is. However I'm currently not sure if it ever tries to write/read
this files while it have an operation going.

> And I wonder why this should be a problem at all as the lvm1 was working
> pretty stable for years now.

lvm2 and lvm1 does not have many in common.

> Am So den 30. Mär 2008 um 10:52 schrieb Bastian Blank:
> > # Automatically generated email from bts, devscripts version 2.9.26
> > severity 419209 important
> The severity of this bug is absolute critical and not just important!

This is up to the maintainer. I use snapshots often and have not seen
such problems recently.


We do not colonize.  We conquer.  We rule.  There is no other way for us.
		-- Rojan, "By Any Other Name", stardate 4657.5

Reply to: