GUI Tools

The command line tools for LVM are not too complicated but for novices it can be a bit daunting. So to help here are 3 GUI tools for LVM.

* EVMS

EVMS? eh? this isn\’t a gui tool it is an alternative volume management systems written mostly by IBM.

Next up LVM+MD?

I tend to split up the system so that it is easier to manage file systems that tend to grow often. For instance if you take the OS, and separate the DATA, then you might end up with something like this.

/dev/os/root
/dev/os/usr
/dev/os/tmp
/dev/os/opt
/dev/os/swap

and the data you may put in a completely different VG like so.

/dev/data/home
/dev/data/var
/dev/data/srv
/dev/data/tmp * some people may choose to do this for systems that do a lot of video and sound editing.

I have experimented, and if you design your servers will then you can utilize your space better, and adapt to any storage issues that may present themselves in the future. I try to leave extra unallocated space in each volume group just in case a file system fills up, then this will allow you to extend the logical volume and the file system resides on that volume. Plan which filesystems you use carefully! Some filesystems (and distribution admin tools) will allow you to extend logical volume and filesystem in one command while others could turn out to be an ordeal.

Hope that helps someone.

http://intelliginix.com

Here are some quick replies and/or comments:

@clowenstein
The example I used in the article was a bit artificial but I wanted to show how you could combine partitions or disks into a VG. One advantage of splitting a disk into partitions and then combining them with LVM is that you could have created stripes across the PV\’s to improve performance. Then again you could have used MD to create RAID groups and also improved performance. I\’ve never dug into the interaction between LVM and MD so I don\’t know what the \”best\” configuration is (however you want to define \”best\”).

@thatblackguy:
Cool approach! I think it takes some work to setup everything as you describe but it does give you much more flexibility than a monolithic approach. Very cool – Thanks!

@mxcreep
The article wasn\’t intended to be an all-encompassing review of LVM with all of the pitfalls and benefits (I think I mentioned that twice which someone pointed out was bad writing – but oh well, I wanted to make sure my point came across). However, the performance penalty doesn\’t really come from LVM. It comes from the fact that the file system has no snapshot capability built in. Consequently, you have to reply on LVM to take the snapshot for you. This forces you to \”freeze\” the file system (so to speak) during the snapshot and means that the file system takes a performance hit during the snapshot.

I also have to be the bearer of bad tidings, but even ZFS suffers a little when a snapshot is taken. The performance penalty is less than having to use ZFS but it\’s still there.

The only time you won\’t see a performance penalty due to a snapshot is for a log based file system because it is designed for snapshots. That\’s one of the really cool features of log based file systems.

I hope that answers some questions. If it doesn\’t feel free to repost and we\’ll figure out the answer together. If it even gets too long, we can write a quick article about the question and the solution (hint, hint) :)

Thanks!

Jeff

My point about performance wasn\’t really about the moment the snapshot was taken but more afterwards. A logical volume with one or more snapshots chained to it performs a lot slower.

Sorry I should have said \”disks\”.

You are correct for a disk (that is the singular form). It\’s not always a good idea (there are situations where it might be reasonable).

For multiple disks (that\’s plural indicating more than one) can give you a performance advantage but it too depends upon the exact configuration.

Jeff