Re: SSD Partitioning OP/Trim recommendations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Dec 18, 2013, at 8:15 AM, Mihamina RKTMB <mihamina@xxxxxxxxx> wrote:

> On 12/18/2013 04:38 PM, Robert Moskowitz wrote:
>> Also discourages using LVM.  I have often wondered why I use LVM on my notebooks; I don't see the gain over just plain EXT4 partitions.  I have read a number of articles and I can't find any solid advantage.
> 
> Well, I dont have a notebook, but a laptop (16GB RAM, Corei7-8 threads, 512 SSD Samsung 840 Pro)
> I use it for work, and I heavily virtualize on it.
> I have 1LV per VM. VMs are "small" (2GB RAM, 5GB disk space), but they are numerous (mostly 4-5 VMs turned on)
> When I clone a VM, the LV gets cloned too.
> I find it very usefull and clean on the drive.

Two other options exist, but first a disclosure being that there are always a bunch of ways to do one thing on linux. And a lot of times it's about comfort level and familiarity rather than what's "best".

The critique I'd apply to using LV's as backing for VM's is that they allocate all of that space - it's taking out of the VG.  So you have to plan in advance accordingly to avoid over committing space that is now no longer in the VG. You can resize but… now that's another series of steps, and you may be resizing again in the future.

So while I used to use LVs for this task, I'm now using qcow2 files. I create one, install once, and then snapshot the qcow2 five times (for five VMs) and have the VMs use the snapshots. The backing qcow2 isn't ever modified from that point forward, only the snapshots are. Since they're sparse, they only take up the space that's actually being used. They're easy to backup, etc.

Another option, that's quite new and probably still needs testing, is LVM Thin Provisioning. There's an extra layer between the VG and LV called the thin pool. LV's are created with a virtual size, meaning they simply get tagged as being that size (think of it as a maximum) but extents aren't taken from the thin pool until needed by any LV using that pool. So instead of creating 5GB LVs, you can create 50G LVs "just in case" it's needed. If one LV needs 1GB, then only 1GB of extents are used in the pool the rest are available to other LVs. Also, it's possible to get efficient snapshotting unlike conventional LVM snapshots. So you can create an LV, install a system, snapshot it to create other LVs and use them as your VM backing. No preallocation for snapshot space required, it draws extents from the pool as each VM's LV needs to grow with changes.


Chris Murphy
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org




[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux