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