Re: Bug#419209: lvm2: Hangs during snapshot creation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am Do den 5. Mär 2009 um 8:46 schrieb Steve Langasek:
> > the whole system break. 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!
>
> Possibly because there are many people using LVM snapshotting who haven't
> seen this bug? I use schroot with LVM snapshots all the time on a server
> running the lenny kernel, and have never seen this bug.
Well, I did also some tests and wasn't able to trigger that bug on my
laptop too. But I also have the lvm direct on the hard disk. On my
server there is a md device underlying. So I suggest the problem is just
with a lvm on top of a md device (which you see not that often on
desktop systems). When I am at home next week (so I can restart the
system by button), I will do a bisect to find out the broken patch. I
just have the complete cvs imported to git now.
But to use the same argumentation than you, there seems to be many
people out there who suffering from this bug.
But as I downgrade the lvm2 back to etch my backup worked this night
since I updated the lvm2 the first time again. So I can prove that the
bug just happened between that two releases reported in the original
report.
> > I did use lvm1 with kernel 2.4 on etch for long time now using exact the
> > same procedure which trigger the problem right now.
>
> Which was not a supported configuration. Linux 2.4 was supported in etch
> only for purposes of upgrading, not for a running system. Your decision to
> run an unsupported system actually makes it harder to track down this bug,
> since the only baseline we have for comparison in your case is a system with
> none of the relevant components in common.
Well, kernel 2.6 wasn't that stable to use it on a productive system.
(And in my opinion it isn't that stable still but there is no way to use
kernel 2.4 in lenny.) For my servers I prefer to have more stability
than more bleeding edge features!
> > Then with the release of lenny I start upgrading my stable systems. This
> > involved a kernel upgrade as lenny only runs with the very instable kernel
> > tree 2.6 and upgrade of the lvm metadata.
>
> Claiming that the 2.6 kernel is unstable only undermines your credibility.
That's your opinion. I did test the 2.6 kernel in several versions now
and it has many instabilities. Also in 2.6 they dropped nearly the
complete oss driver so I have no sound. (The alsa driver never worked in
all of my environments. It takes just 5 minutes to get a kernel panic if
I try to use alsa. And yes, I test it also with several hardware and
with many kernel versions.) Altogether I think that the kernel
developer has to start a development tree to get the 2.6 series calm
down and get stable. Until now there is no 2.6 release which is that
stable then the kernel 2.4.
> > Days after I noticed that apt-get install froze randomly and I had to
> > reboot the system with a power cycle (reboot didn't work). First I was
> > thinking about one of the many kernel bugs in 2.6 and tried the newest
> > kernel from kernel.org. But the bug was still there. After several days
> > I end in finding the problem in the LVM2 subsystem and two days later,
> > today, I found this ug report and was very shocked! If I had know of it
> > before I had never upgrade any of may stable systems to lenny! But now
> > one of them is sticked on lenny as I know no way to revert the LVM back
> > to LVM1.
>
> The original bug reporter claims that the hang only occurs with newer
> versions of the lvm2 userspace tools. You could try downgrading to the etch
> version of lvm2, to see whether this resolves the problem for you.
As I mention above I can prove that this solves my problem. So the buggy
path is just in between.
> > 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. 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.
>
> What does dmesg show for the system after the snapshot has hung?
Nothing. I also raised the log level of lvm to 7 (debug) but there is
nothing special in the log. The last lines are:
libdm-deptree.c:1187 Creating sysvg-lv_usr-real
ioctl/libdm-iface.c:1606 dm create sysvg-lv_usr-real LVM-aVvQkLwPuENl6auLtoUWJBqjM0OKG0NQ00000000000000000000000000000000-real NF [16384]
libdm-common.c:607 sysvg-lv_usr-real: Stacking NODE_ADD (253,9) 0:6 0660
libdm-deptree.c:1463 Loading sysvg-lv_usr-real table
libdm-deptree.c:1413 Adding target: 0 14024704 linear 9:0 97714560
libdm-deptree.c:1413 Adding target: 14024704 2752512 linear 9:0 65920
ioctl/libdm-iface.c:1606 dm table (253:9) OF [16384]
ioctl/libdm-iface.c:1606 dm reload (253:9) NF [16384]
libdm-deptree.c:897 Resuming sysvg-lv_usr-real (253:9)
ioctl/libdm-iface.c:1606 dm resume (253:9) NF [16384]
libdm-common.c:635 sysvg-lv_usr-real: Stacking NODE_READ_AHEAD 1024 (flags=0)
libdm-deptree.c:1463 Loading sysvg-lv_usr table
libdm-deptree.c:1413 Adding target: 0 16777216 snapshot-origin 253:9
ioctl/libdm-iface.c:1606 dm table (253:0) OF [16384]
ioctl/libdm-iface.c:1606 dm reload (253:0) NF [16384]
libdm-deptree.c:1187 Creating sysvg-sv_usr-cow
ioctl/libdm-iface.c:1606 dm create sysvg-sv_usr-cow LVM-aVvQkLwPuENl6auLtoUWJBqjM0OKG0NQy2tplW0aa8Sb2JSSOLdRC0r3JhnJ00NC-cow NF [16384]
libdm-common.c:607 sysvg-sv_usr-cow: Stacking NODE_ADD (253,10) 0:6 0660
libdm-deptree.c:1463 Loading sysvg-sv_usr-cow table
libdm-deptree.c:1413 Adding target: 0 1048576 linear 9:0 434176384
ioctl/libdm-iface.c:1606 dm table (253:10) OF [16384]
ioctl/libdm-iface.c:1606 dm reload (253:10) NF [16384]
libdm-deptree.c:897 Resuming sysvg-sv_usr-cow (253:10)
ioctl/libdm-iface.c:1606 dm resume (253:10) NF [16384]
libdm-common.c:635 sysvg-sv_usr-cow: Stacking NODE_READ_AHEAD 0 (flags=1)
libdm-deptree.c:1463 Loading sysvg-sv_usr table
libdm-deptree.c:1413 Adding target: 0 16777216 snapshot 253:9 253:10 P 8
ioctl/libdm-iface.c:1606 dm table (253:8) OF [16384]
ioctl/libdm-iface.c:1606 dm reload (253:8) NF [16384]
activate/fs.c:167 Removing /dev/sysvg/lv_usr
activate/fs.c:174 Linking /dev/sysvg/lv_usr -> /dev/mapper/sysvg-lv_usr
activate/fs.c:167 Removing /dev/sysvg/sv_usr
activate/fs.c:174 Linking /dev/sysvg/sv_usr -> /dev/mapper/sysvg-sv_usr
Which seems to look just normal for me. But well, I do not know how it
SHOULD look like.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQEVAwUBSa+UTZ+OKpjRpO3lAQro8Af/fdtvn0lda808Pm7l9hVtRspUaVDh3BLM
sFa8E+2g+OgKMM7n+ZGdZqZ/pxpWsEDkX/SDeHC9xB9q0TMbkICaIUjw565dapr9
Di6W8VJBEEGCCzFHVcBzP7SiOmernEu8NrXe9+isjnDGmbjsuxsypF4xQ7LApa+J
tKqy6/S5D/QVFyYnO+3r9g8dFmqN4cflUHgbACdHJpfIBgq6+AjyvictJVnHpimc
j/bt+n4j/m7c5IuAoPaUIwgK2JxMiHqU3H7+dYsZ7VFp+8iBPGrtBoRNlvE10G79
ifHh74h8gN0g4TiQNmezFR6suhfv9hmOLSEqaftvgTuLWg20pEa3Vw==
=EnRv
-----END PGP SIGNATURE-----
Reply to: