On Friday 25 March 2011 07:51:13 Joost Roeleveld wrote: > On Thursday 24 March 2011 22:07:28 Volker Armin Hemmann wrote: > > On Thursday 24 March 2011 12:08:02 Alan McKinnon wrote: > > > On Thursday 24 March 2011 12:19:39 Dale wrote: > > > > I have never used LVM but when it messes up after a upgrade, as > > > > has > > > > happened to many others, see if you say the same thing. I hope > > > > your > > > > backups are good and they can restore. > > > > > > What is this "mess up after an upgrade" of which you speak? > > > > > > I've used multiple versions of LVM on multiple machines across > > > multiple > > > distros for multiple years and never once heard of anyone having a > > > problem with it let along experienced one myself. > > > > > > Shades of FUD methinks. > > > > http://bugs.gentoo.org/buglist.cgi?quicksearch=lvm > > > or if you like a bit of history: > Not all of these are LVM, some are only shown because they're related to > llvm (Which is a virtual machine), but lets ignore those all-together :)
I know, I am just too lazy to do a more 'sophisticated' search. > > On the first page, at first glance, I don't see any serious ones that are > only LVM. > The boot-issue was caused by genkernel not being up-to-date with > name-changes. > > > http://bugs.gentoo.org/buglist.cgi?quicksearch=ALL+lvm > > there you go. > > See above see above. But if you look only at the lvm bugs there are enough examples of bad kernel/lvm/whatever interaction. It does not matter that it was baselayout or another update that stopped lvm from working. If your system does not boot it does not boot - lvm seems to make that more likely. > > > I like this one: > > http://bugs.gentoo.org/show_bug.cgi?id=350455 > > Looks like an issue with heavy I/O, affecting the LVM layer trying to lock > the filesystem. > > But I wonder if he's not running into a known issue (which can easily be > worked around) where pvmove has a memory-leak with the reporting. (eg. the > bit that checks the progress every 5 seconds, reducing that to every 5 > minutes significantly reduces that) > However, I do believe this (mem-leak) was fixed. > > Am curious what the result will be of that. Please note, I do not run masked > (~amd64) kernels. oh, even better, a memory leak. pvmove even. I remember one bug where a commenter mentioned that pvmove nuked all data on a non-lvm partition. Great stuff. It does not matter that you might not run 'unstable' kernels. Some people like to be a bit more update for very valid reasons (drivers). With lvms history that doesn't look so good.
