I saw in this question that it is possible to place both a SSD and a standard SATA hard drive into a single LVM volume group (VG).

How does this affect performance?

Is there a way to force the OS to be on the SSD while the data is on the SATA drive within a single volume group?

Are there any good whitepapers on using LVM with different types of drives?

Would it be beneficial to create a VG for each drive type and/or speed? I was thinking of creating one VG for SSDs and one for SATA (and for each drive type I may add in the future as it comes).

  • related - unix.stackexchange.com/questions/7122/…
    – Graeme
    Mar 18, 2014 at 17:37
  • My intuition is that it would be a really bad idea to put both a SSD and a conventional hard disk in the same volume group.
    – samiam
    Mar 18, 2014 at 17:41
  • @samiam that was my initial thought. I wasn't sure if there were ways to tell the LVM to always place data going to and from such-and-such directory to sda and always place data going to another directory on sdb.
    – Nick
    Mar 18, 2014 at 17:50
  • @Graeme that talks a lot about performance, but I didn't see anything related to spanning different disk types, which is what I'm mainly concerned with. If I missed something, please point it out.
    – Nick
    Mar 18, 2014 at 17:50
  • Nick: I can't answer about LVM from the top of my head, but, yes, it's possible to set up /etc/fstab so that / is on a SSD but anything below /home is on a conventional hard disk. This is usually an option while installing any modern Linux system (/home would be a "mount point" when choosing some form of "advanced options")
    – samiam
    Mar 18, 2014 at 17:52

2 Answers 2


What you can do in recent-ish LVM versions is create one “origin” LV on the HDD and one “cache pool” LV on the SSD, and then combine it into a single “cache” LV. It has the same size as the “origin” LV (i.  e., you only get as much space as is on the HDD), but frequently used blocks and metadata are cached on the SSD to improve performance.

The gist of it is, assuming you already have a VG spanning both drives:

lvcreate -l 100%PVS -n your_name YourVG /dev/YourHDD
lvcreate --type cache-pool -l 100%PVS -n your_name_cache YourVG /dev/YourSSD
lvconvert --type cache --cachepool YourVG/your_name_cache YourVG/your_name

After that, you will have a your_name LV that you can use like any other LV, and several internal LVs that you can see with lvs -a YourVG.

For example, I set up an encrypted root filesystem across an SSD partition (/dev/sda3) and an HDD partition (/dev/sdb1) with the following commands:

pvcreate /dev/sda3 /dev/sdb1
vgcreate RootVG /dev/sda3 /dev/sdb1
lvcreate -l 100%PVS -n cryptroot RootVG /dev/sdb1
lvcreate --type cache-pool -l 100%PVS -n cryptroot_cache RootVG /dev/sda3
lvconvert --type cache --cachepool RootVG/cryptroot_cache RootVG/cryptroot
cryptsetup luksFormat --type luks2 /dev/RootVG/cryptroot

You can find more details on this blog post or this one. (The first one is what I used for reference and is also used as a reference on the LVM Wikipedia article; the second one is by me, describing how I used it in practice. Decide for yourself which one you want to trust 😉)


LVM does not distinguish between a fast and a slow disk. Is it seems not to be a good idea to put those disk's to one LVM volume group.

Beside of this, it is always good to mount your /tmp directory on a SSD which provides a huge speedup, especially for applications that use it like compiling.

  • 6
    Put /tmp on tmpfs. More performance, less wear on the SSD (or on the hard disk for that matter). SSD's very fast reads make it mostly useful for data that is read more often than it's written. Mar 18, 2014 at 23:35
  • 1
    What was discovered as a vulnerability? Mar 19, 2014 at 0:43
  • 1
    – user55518
    Mar 19, 2014 at 0:45
  • 7
    Meh. I generally want files in /tmp to be cleaned on reboot — if they're meant to stay, that's what /var/tmp is for. I've used tmpfs for /tmp for years on many machines and have never come close to running out of swap space, and I don't have atypically small amounts of data in /tmp, so that argument is bogus. In any case, it isn't a vulnerability — that word implies a security problem. Mar 19, 2014 at 1:09
  • 1
    it seems you don't have any bad users to serve. If you don't want to call it vulnerability, then call it harmful, in any case it's not recommended except you know what you are doing.
    – user55518
    Mar 19, 2014 at 14:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .