I just ordered a new machine that's destined to become a Centos 6 application server for a publishing company, and decided to get one with a 40GB SSD as well as a standard hard drive.
I'm thinking that I can put most of the operating system on that drive and have the home directories and whatnot on the regular hard drive. Are there any pitfalls lying in wait for an unwary person like me when setting this thing up?
Further, I suspect that if that thing rattles along like I think it should I'll probably want to add a SSD to my own desktop machine here. Since this computer is already set up with the default Centos 6 partitioning system on a single hard drive (/boot, /home and /) is there an easy way to transfer the OS to the SSD or would I be better off reformatting this thing and starting over from scratch if I want to have a SSD for my boot and OS drive?
On 04/13/12 2:59 PM, Frank Cox wrote:
I just ordered a new machine that's destined to become a Centos 6 application server for a publishing company, and decided to get one with a 40GB SSD as well as a standard hard drive.
I'm thinking that I can put most of the operating system on that drive and have the home directories and whatnot on the regular hard drive. Are there any pitfalls lying in wait for an unwary person like me when setting this thing up?
Further, I suspect that if that thing rattles along like I think it should I'll probably want to add a SSD to my own desktop machine here. Since this computer is already set up with the default Centos 6 partitioning system on a single hard drive (/boot, /home and /) is there an easy way to transfer the OS to the SSD or would I be better off reformatting this thing and starting over from scratch if I want to have a SSD for my boot and OS drive?
a server typically makes very little access of the system drive once the OS and services are loaded... sure, the boot time will be hugely sped up, but how often do you reboot a production server?
typically, the most important storage IO function on an application server is the database performance, and this requires a device with strong random write performance.
On Fri, 13 Apr 2012 15:27:16 -0700 John R Pierce wrote:
a server typically makes very little access of the system drive once the OS and services are loaded... sure, the boot time will be hugely sped up, but how often do you reboot a production server?
This is an application server with a bunch of terminals that hang off of it. The idea is to have "instant on" for stuff like Gimp, Scribus, Inkscape, LibreOffice, and whatnot which I'm thinking would live on the SSD. The data files, caches and so on would be in the user's home directories and a big shared directory, all on the standard hd as usual.
Is there some reason why this won't work that I'm not seeing?
On 04/13/12 3:42 PM, Frank Cox wrote:
This is an application server with a bunch of terminals that hang off of it. The idea is to have "instant on" for stuff like Gimp, Scribus, Inkscape, LibreOffice, and whatnot which I'm thinking would live on the SSD. The data files, caches and so on would be in the user's home directories and a big shared directory, all on the standard hd as usual.
ah, i would call that a 'terminal server', thats quite a different workload then. I was thinking of 'application server' as something like Tomcat, providing webservices.
even so, I'd expect all those applications to be cached in main memory once they are loaded the first time, unless this server is also memory constrained.
On Fri, 13 Apr 2012 15:50:19 -0700 John R Pierce wrote:
ah, i would call that a 'terminal server', thats quite a different workload then. I was thinking of 'application server' as something like Tomcat, providing webservices.
I thought about calling it that, but when I think of a terminal server I think of something like a POS system that runs one program on a stack of terminals. This is more of a centralized desktop application thing.
even so, I'd expect all those applications to be cached in main memory once they are loaded the first time, unless this server is also memory constrained.
Well, users and applications come and go all day long and since this is a publishing company some of the files get pretty honkin' huge.
The SSD is about $100 or so, so I figure at that price it's worth having for any gain that can be had, even if it isn't a blow-your-mind improvement under field circumstances.
On Apr 13, 2012, at 5:59 PM, Frank Cox wrote:
I just ordered a new machine that's destined to become a Centos 6 application server for a publishing company, and decided to get one with a 40GB SSD as well as a standard hard drive.
I'm thinking that I can put most of the operating system on that drive and have the home directories and whatnot on the regular hard drive. Are there any pitfalls lying in wait for an unwary person like me when setting this thing up?
Further, I suspect that if that thing rattles along like I think it should I'll probably want to add a SSD to my own desktop machine here. Since this computer is already set up with the default Centos 6 partitioning system on a single hard drive (/boot, /home and /) is there an easy way to transfer the OS to the SSD or would I be better off reformatting this thing and starting over from scratch if I want to have a SSD for my boot and OS drive?
I use this setup (albeit a bigger SSD) on a few systems.
Some workstations for my power users and some of my servers.
Works fine, stick with the Intel X series, not the M.
Although there new gear looks killer;
http://www.intel.com/content/www/us/en/solid-state-drives/ssd-910-series-spe...
Plugs direct into a PCIe slot, pretty shweeeet.
We need the bandwidth so this may be over kill for you, but still its cool.
- aurf
On 04/13/2012 06:00 PM, aurfalien wrote:
Oh yea, sorry. Yep you got it, the OCZs.
There is a significant mortality rate with consumer grade SSDs. If you are going to use one, pair it up in a software RAID1 with some matching partitions on the hard drive and then adjust the RAID to read preferentially from the SSD. See http://superuser.com/questions/293144/combining-ssd-and-hard-disk-in-softwar... for some links explaining how to do that.
That way when the drive fails you aren't left with a completely crashed system.
For any production system like this you should be using RAID anyway.
On Sat, 14 Apr 2012 07:00:37 -0700 Benjamin Franz wrote:
There is a significant mortality rate with consumer grade SSDs. If you are going to use one, pair it up in a software RAID1 with some matching partitions on the hard drive and then adjust the RAID to read preferentially from the SSD. See http://superuser.com/questions/293144/combining-ssd-and-hard-disk-in-softwar... for some links explaining how to do that.
I'm just thinking... I wonder if it would be possible to somehow replicate the OS on both the SSD and the hard drive, such that you could just change the boot device in the bios to point to one or the other. Which wouldn't exactly be a raid (with the overhead that entails) but just a change of boot device as required.
On 4/15/12, Frank Cox theatre@melvilletheatre.com wrote:
I'm just thinking... I wonder if it would be possible to somehow replicate the OS on both the SSD and the hard drive, such that you could just change the boot device in the bios to point to one or the other. Which wouldn't exactly be a raid (with the overhead that entails) but just a change of boot device as required.
This is an interesting idea, especially with using a small cheap SSD to boost boot speed.
Don't see any reason why it cannot be achieved simply by doing the same thing of using mdraid RAID 1 with partitions and using the write-mostly on the HDD partitions.
On Sat, Apr 14, 2012 at 11:39 AM, Frank Cox theatre@melvilletheatre.com wrote:
There is a significant mortality rate with consumer grade SSDs. If you are going to use one, pair it up in a software RAID1 with some matching partitions on the hard drive and then adjust the RAID to read preferentially from the SSD. See http://superuser.com/questions/293144/combining-ssd-and-hard-disk-in-softwar... for some links explaining how to do that.
I'm just thinking... I wonder if it would be possible to somehow replicate the OS on both the SSD and the hard drive, such that you could just change the boot device in the bios to point to one or the other. Which wouldn't exactly be a raid (with the overhead that entails) but just a change of boot device as required.
I don't know if there have been any real tests, but I'd expect that for most real-world use you would get much better performance if you spent the same money on additional RAM instead, since the OS will automatically use it for disk cache. There might be exceptions for specific applications where you could tune the SSD to hold things the application needs but that might otherwise be evicted from cache.
In article 20120413155934.fcdaa9db.theatre@melvilletheatre.com, Frank Cox theatre@melvilletheatre.com wrote:
I just ordered a new machine that's destined to become a Centos 6 application server for a publishing company, and decided to get one with a 40GB SSD as well as a standard hard drive.
I'm thinking that I can put most of the operating system on that drive and have the home directories and whatnot on the regular hard drive. Are there any pitfalls lying in wait for an unwary person like me when setting this thing up?
Further, I suspect that if that thing rattles along like I think it should I'll probably want to add a SSD to my own desktop machine here. Since this computer is already set up with the default Centos 6 partitioning system on a single hard drive (/boot, /home and /) is there an easy way to transfer the OS to the SSD or would I be better off reformatting this thing and starting over from scratch if I want to have a SSD for my boot and OS drive?
I haven't tried it, but my natural reaction would be to have /home and /var on the regular HD, and also /tmp if it's not on tmpfs. Then /boot and the rest of / on the SSD.
Cheers Tony