Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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).

share|improve this question
FYI: LVM is the name for the kernel subsystem. The disks are called "physical volumes" (PV). Multiple PVs are combined into "volume groups" (VG). Each VG can be carved into one more "logical volumes" (LVs). LVs are where you actually put, say, a filesystem. I'm going edit your question to change LVM to the appropriate one, please confirm I've understood correctly. –  derobert Mar 18 '14 at 17:04
related - unix.stackexchange.com/questions/7122/… –  Graeme Mar 18 '14 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 '14 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 '14 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 '14 at 17:50

1 Answer 1

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.

share|improve this answer
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. –  Gilles Mar 18 '14 at 23:35
this was discovered as a vulnerability and is not more provided by many distributions. –  user55518 Mar 19 '14 at 0:34
What was discovered as a vulnerability? –  Gilles Mar 19 '14 at 0:43
rwmj.wordpress.com/2012/09/12/tmpfs-considered-harmful –  user55518 Mar 19 '14 at 0:45
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. –  Gilles Mar 19 '14 at 1:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.