Re: [gentoo-user] LVM (Was: the best filesystem for server: XFS or JFS (or?))

[Volker Armin Hemmann <volkerarmin@googlemail.com>]

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.