A problem of expectations, not of Linux volume Management
|
| Author | Content |
|---|---|
| texastwister Jul 24, 2008 10:04 AM EDT |
This seems a problem of improper expectations and lack of foresight, rather than of the Linux volume Management tools themselves. You're asking a set of tools to be able do whatever you currently need, rather than what they were designed to do. LVM is designed to provide flexible volume management within Linux and it does that well. It is not designed to provide fault-tolerance, nor to accommodate Windows. MDADM software raid is designed to provide fault-tolerance and the performance benefits of RAID and it does that well. It is not designed to provide flexible volume management, nor to accommodate Windows. Your initial setup was designed to provide flexible volume management with fault-tolerance within Linux -- and it does that well. But you were not thinking ahead to accommodate Windows. Can't blame Linux, LVM, or even EVMS for that! Could it have been done, using the same tools, but with greater foresight? Sure -- here's how: Let's say you want the flexibility of being able to repurpose the diskspace however you like in 10 G chunks... Take your two 80G disks, carve out space for /boot as you describe above, then partition the rest of the disks identically in a series of 10G partitions and a final partition of whatever is left. Now, use software raid to mirror each pair: sda2 + sdb2 = md0, sda3 + sdb3 = md1, etc. That leaves you with two partitions used for /boot and a series of software RAID devices (md0, md1, md2, etc.). Initialize each RAID device as an LVM physical volume and add them all to the volume group. At this point -- the result is the same as your setup. You have 2 G for /boot and roughly 71G in a volume group for use with your logical volumes. But NOW, to make room for Windows, you need only resize filesystems as needed, resize logical volumes as needed, use pvmove to move all data off of one of the 10 G raid devices acting as physical volumes and you can remove that raid device from the volume group. Then you could disassemble the raid device and you would have two 10 G partitions available for use by Windows. As an aside, you really should get over your dislike of initrd and the command line tools. initrd is widely used in enterprise systems and works very well. And mdadm and lvm are easy, easy to use at the command line with just a little practice. |
| tuxchick Jul 24, 2008 12:15 PM EDT |
I agree with Hans. All of these tools are related and are commonly used together, so it would be great to have a nice unified interface, whether it's a GUI or a console tool. That doesn't change the underlying tools being distinct and separate. GParted, which is mentioned in the article, is a great example of an excellent front-end tool that brings together several different but related programs- partitioning, resizing and moving partitions, and filesystem management. GParted is a lot faster and easier than running all the individual programs that lie under its hood. |
| hkwint Jul 25, 2008 1:06 AM EDT |
Quoting:You're asking a set of tools to be able do whatever you currently need Maybe. I see it more like this: I was hoping EVMS would do whatever I currently need. I'm not blaming LVM or mdadm; they don't pretend to be the all-in solution. But I however agree the expectations are the most important problem; if I have had lower expectations of EVMS I would have left more HD-space unused probably. Anyway, I hope some people with EVMS-expectations read this article to make their expectations more 'real-world'. Back to LVM/mdadm: maybe that wasn't clear from the article; in fact I do like LVM and mdadm very much. LVM never let me down, and both LVM and mdadm didn't create my troubles, and even could have prevented my troubles. I also like to use the command line, but basically the problem is other people want to do the same things without using the CLI. For me, it was more like 'why use the CLI (LVM/mdadm) if a GUI is available?' Quoting:But you were not thinking ahead to accommodate Windows I did plan that in fact. But of course, 2GB is far too less. Being used to Linux however, I did think it was enough when I partitioned my HD. I also didn't know about Inventor HD requirements back then. So there was some thinking ahead, but not enough. Quoting:Let's say you want the flexibility of being able to repurpose the diskspace however you like in 10 G chunks... Take your two 80G disks, carve out space for /boot as you describe above, then partition the rest of the disks identically in a series of 10G partitions That's exactly what I thought and was planning to do! However, after the 'foresight problems' I kind of 'locked myself in' to EVMS and this wasn't possible anymore. Yes, it would have been if I had used 'mdadm' to shrink my RAID partition like Sander suggests in the other thread. But I didn't know that was the way to go. If I had asked on some forum instead of just try & pray I would have got better results. Consider that a lesson learned! Quoting:GParted is a lot faster and easier than running all the individual programs that lie under its hood. Indeed, that's what I was trying to say Carla. EVMS is faster and easier than running all of the individual programs. You can use the EVMS CLI too if you want; I normally use the GUI or ncurses GUI if X isn't available. But it doesn't have all the capabilities the individual programs under its hood have. I'm not blaming (IBM for stopping to maintain) EVMS, in fact I was glad it existed - and still does. However, I find it very sad to see some IBM-devs working on the new Aperi project while the other former IBM-project EVMS is being unmaintained. |
| brem Aug 03, 2008 11:15 AM EDT |
Hi, I do not totally agree with you guys when you say that LVM is not designed to provide fault-tolerance. There is a RAID mirroring solution within LVM (lvconvert -m1 ...). I think the problem is always the same, a few teams working on different products to reach the same goal, MD team and LVM team, which finally feeds the confusion down here. 1) DM-Multipath provides multipath 2) MD provides RAID and also provides multipath -- I think in a failover fashion only ! 3) LVM2 provides volume management and also RAID (1 and may be more). The question that always get asked is : What solution do I need to use to be completely redundant and optimal. In clear, what are the best practices to provide to my computer (imagine a server with critical apps) both optimal path load-balancing, maximum security by eliminating disks SPOF's, and flexibility by allowing me to resize a FS if needed. As I did, you have to try different solutions to reach the not less complex one, use these 3 tools jointly even if, on, the paper 2 would have been sufficient. For information, mirroring with LVM is quite simple, but when you get to resize your LV's, you then discover that you have to first split your mirrors. I'm not even mentioning the need of a 3rd disk to keep the mirror metadata !!! I think having a look at the other unices (HP-UX, Solaris, though I consider HP-UX superior in terms of volume mgmt than Solaris before ZFS gets completely considered production ready ) and take the ideas. Brem |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!