I mentioned here the other day that I was planning to set up a Centos 6 system using a SSD for the system drive and a regular hard drive for a data drive.
My plan is to have everything that doesn't change (much) on the SSD, such as /boot, /lib, /bin and so on. I want to put /tmp and /var and /home on the regular hard drive.
Now that I'm at the stage of actually setting this up I have discovered that I don't understand enough about drive partitioning to make this work the way that I want it to. Perhaps I'm missing something obvious.
I could create separate partitions on the SSD for /lib, /bin and everything else that I want to put there, then put / on the hard drive, but I would really prefer to put /boot and one other partition on the SSD, and one partition on the hard drive.
How can I tell the system that I want /bin and friends on the SSD and /home and /var on the hard drive, but still have just one partition on each drive (plus /boot on the SSD)? If I create / on the hard drive and /ssd on the SSD, then putting bin on the SSD would make it /ssd/bin and that would obviously not be what I want to see.
Well, /boot by default, is always a primary partition.
CentOS (and RedHat) like to create a logical volume manager (LVM) on a separate primary partition, and typically inside the LVM one can create and modify the rest of the various partitions.
You do have the flexibility to create TWO LVM's. You can place one LVM on a primary partition on the SSD, and the other on the hard drive. From within both LVM's you can create your partitions to your heart's content.
Or for your SSD configuration, don't bother creating an LVM for that. You can use up to 4 primary partition per storage device (and lots of secondary partitions). So, since you only want to place two partitions total on the SSD, simply create those two primary partitions and utilize them. === Al
________________________________ From: Frank Cox theatre@melvilletheatre.com To: centos@centos.org Sent: Tuesday, April 17, 2012 3:40 PM Subject: [CentOS] SSD as system drive - partitioning question
I mentioned here the other day that I was planning to set up a Centos 6 system using a SSD for the system drive and a regular hard drive for a data drive.
My plan is to have everything that doesn't change (much) on the SSD, such as /boot, /lib, /bin and so on. I want to put /tmp and /var and /home on the regular hard drive.
Now that I'm at the stage of actually setting this up I have discovered that I don't understand enough about drive partitioning to make this work the way that I want it to. Perhaps I'm missing something obvious.
I could create separate partitions on the SSD for /lib, /bin and everything else that I want to put there, then put / on the hard drive, but I would really prefer to put /boot and one other partition on the SSD, and one partition on the hard drive.
How can I tell the system that I want /bin and friends on the SSD and /home and /var on the hard drive, but still have just one partition on each drive (plus /boot on the SSD)? If I create / on the hard drive and /ssd on the SSD, then putting bin on the SSD would make it /ssd/bin and that would obviously not be what I want to see.
On 04/17/2012 06:40 PM, Frank Cox wrote:
I mentioned here the other day that I was planning to set up a Centos 6 system using a SSD for the system drive and a regular hard drive for a data drive.
My plan is to have everything that doesn't change (much) on the SSD, such as /boot, /lib, /bin and so on. I want to put /tmp and /var and /home on the regular hard drive.
Now that I'm at the stage of actually setting this up I have discovered that I don't understand enough about drive partitioning to make this work the way that I want it to. Perhaps I'm missing something obvious.
I could create separate partitions on the SSD for /lib, /bin and everything else that I want to put there, then put / on the hard drive, but I would really prefer to put /boot and one other partition on the SSD, and one partition on the hard drive.
You're going to find it very difficult to separate /lib and /bin from the root file system. When the kernel starts up, it has just the root file system. How can it execute the "mount" command to gain access to /lib and /bin when the mount command and the libraries it needs are on a file system that has not yet been mounted? It's far more straightforward and more maintainable to put the root file system on the SSD and put /tmp, /var, and /home on the regular drive.
Most writes to the root file system (other than root's home directory) occur only during configuration changes (file system mounts/umounts, network link starts/stops, modifying printers, ...) and much of that could be moved off of the root file system with judicious use of symlinks. I just now ran the 'find' command to see what on the root file system had a time stamp more recent than the time of the last boot (10 days ago, BTW) and filtering out root's home directory and mount point directories and there was almost nothing. About the only thing that would be any challenge to symlink away would be /etc/mtab, and it's going to be awfully hard to wear out an SSD with a file that gets written once for each mount or umount.
On Tuesday, 17. April 2012. 17.40.32 Frank Cox wrote:
My plan is to have everything that doesn't change (much) on the SSD, such as /boot, /lib, /bin and so on. I want to put /tmp and /var and /home on the regular hard drive.
Now that I'm at the stage of actually setting this up I have discovered that I don't understand enough about drive partitioning to make this work the way that I want it to. Perhaps I'm missing something obvious.
I could create separate partitions on the SSD for /lib, /bin and everything else that I want to put there, then put / on the hard drive, but I would really prefer to put /boot and one other partition on the SSD, and one partition on the hard drive.
How can I tell the system that I want /bin and friends on the SSD and /home and /var on the hard drive, but still have just one partition on each drive (plus /boot on the SSD)? If I create / on the hard drive and /ssd on the SSD, then putting bin on the SSD would make it /ssd/bin and that would obviously not be what I want to see.
You want to create two partitions on the SSD and three on the HD. The SSD partitions should have the mount points /boot and /, while the HD partitions should have mount points /tmp, /var and /home. That's all there is to it, really.
It seems that you are just missing the observation that (by default) everything that does not have its own mount point will be put as a directory into / during the installation. However, directories that *do* have their own mount points will be put on their respective drives, and just logically "mounted" into the / tree. So you just create separate partitions for stuff you want to go to the HD, and everything else will go inside the / partition, which should be on the SSD.
Btw, I stopped bothering to create a separate /boot partition some time ago, and never looked back... What is your usecase for having it separated from / ?
HTH, :-) Marko
On Wed, 18 Apr 2012 08:56:03 +0200 Marko Vojinovic wrote:
You want to create two partitions on the SSD and three on the HD. The SSD partitions should have the mount points /boot and /, while the HD partitions should have mount points /tmp, /var and /home. That's all there is to it, really.
It seems that you are just missing the observation that (by default) everything that does not have its own mount point will be put as a directory into / during the installation. However, directories that *do* have their own mount points will be put on their respective drives, and just logically "mounted" into the / tree. So you just create separate partitions for stuff you want to go to the HD, and everything else will go inside the / partition, which should be on the SSD.
Aha! The light just came on for me here. Thanks to everyone for your observations and insight on this; I now have a better understanding of drive partitioning than I did before.
I just now started formatting this new machine.
Btw, I stopped bothering to create a separate /boot partition some time ago, and never looked back... What is your usecase for having it separated from / ?
Nothing, other than that's how the default partition scheme seems to work on my other Centos installations so I figured if that's the default there must be a good reason for it.
On Wed, Apr 18, 2012 at 2:05 AM, Frank Cox theatre@melvilletheatre.com wrote:
You want to create two partitions on the SSD and three on the HD. The SSD partitions should have the mount points /boot and /, while the HD partitions should have mount points /tmp, /var and /home. That's all there is to it, really.
It seems that you are just missing the observation that (by default) everything that does not have its own mount point will be put as a directory into / during the installation. However, directories that *do* have their own mount points will be put on their respective drives, and just logically "mounted" into the / tree. So you just create separate partitions for stuff you want to go to the HD, and everything else will go inside the / partition, which should be on the SSD.
Aha! The light just came on for me here. Thanks to everyone for your observations and insight on this; I now have a better understanding of drive partitioning than I did before.
The original unix layout split /bin, /lib and /usr/bin, /usr/lib with the intent that everything you need to boot and mount other partitions had to be in /bin and /lib on the root partition which might be tiny. After years of big, cheap media availability things have gotten sloppy but booting from an ssd puts it back in perspective.
I just now started formatting this new machine.
Btw, I stopped bothering to create a separate /boot partition some time ago, and never looked back... What is your usecase for having it separated from / ?
Nothing, other than that's how the default partition scheme seems to work on my other Centos installations so I figured if that's the default there must be a good reason for it.
Eons ago, PC bios didn't know how to boot data beyond cylinder 1024 - long after disks were bigger than that. So the safest approach was to make a small /boot partition as the first thing on the disk. It still works and has no harmful side effects as long as it has enough space to hold future kernels and initrds. It also lets you use LVM and filesystems that grub doesn't understand for your root filesystem.
-
Al Sparks -
Frank Cox -
Les Mikesell -
Marko Vojinovic -
Robert Nichols