Another case of WONTFIX

Duncan 1i5t5.duncan at cox.net
Sun Apr 17 15:01:16 BST 2011


Kevin Krammer posted on Sun, 17 Apr 2011 13:36:10 +0200 as excerpted:

> On Friday, 2011-04-15, Boyd Stephen Smith Jr. wrote:
>> In <201104151329.18065.gheskett at wdtv.com>, gene heskett wrote:
>> >LVM?  Having had it self-destruct with no chance of recovering a
>> >single byte, twice now, that's one utility I don't allow, ever.  No
>> >recovery tools at all?  Shoot it and put it out of my misery.
>> 
>> LVM?  Having used it for 6 years, cleanly migrating my data live at
>> least 3 times, at least once screwing it up myself and finding the
>> recovery tools excellent, that's one tool I'll never do without, ever. 
>> If you aren't using LVM, you are likely doing something wrong.
> 
> Haven't had to do any recovery yet but have been using it for about the
> same timeframe myself on several computers.
> 
> But I guess it depends a bit on how one updates, i.e. when on a
> distribution with rolling updates one has to be careful to update user
> space and kernel space components in a compatible way.

I never had a functional issue with it when I was running lvm.

I just decided the complexity involved was simply too high, sitting as it 
was along with md/raid as yet another layer between the filesystems and 
the physical storage devices.  Recovery situations are stressful enough as 
it is, without yet another layer with its own arcane config and command 
line syntax to worry about.

Plus, because unlike md/raid, lvm must be configured at every run from 
userspace, either lvm can't be run on root itself, rather limiting its 
flexibility which is much of its point, or if it is to be run on root, it 
requires an initr*, adding yet MORE complexity to an otherwise reasonably 
simple initr*-less boot.

I thus decided that with the limited flexibility since it couldn't run on 
root without an initr*, and with the complexity of the config and recovery 
command line, the limited benefits simply weren't worth the cost.

I'm glad I did.  md/raid is quite flexible indeed, given that it can run 
on top of partitions, and that it can now be partitioned as well, plus I 
can run several root and root-bak raids, configuring them as necessary 
directly from the grub command line and pointing root= at the one I want 
to start.  That makes recovery from a serious issue generally quite easy, 
since all I have to do is tell the kernel to startup the backup root md/
raid and point the root= parameter at the rootfs on that raid. (There's 
additional backups on external, of course, if all four drives in the 
raid-1s die or the whole thing is stolen or the like.)

Now if lvm didn't require runtime userspace configuration, and could be 
configured directly from grub as can md/raid, it'd be a different story, 
as its flexibility would have then been FAR higher, thus likely raising 
the benefits above the risk and hassle costs.  But those are IFs that 
don't seem likely any time soon, so...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.




More information about the kde mailing list