up vote 1 down vote favorite
share [g+] share [fb]

Yesterday I got my new workstation featuring:

  • 120 GB - OCZ Vertex3 MAX IOPS
  • 300 GB - Western Digital Velociraptor (10k RPM, about 4ms avg. seek)
  • 2x2TB Samsung Ecogreen F4

The system will be running Ubuntu with the main purpose of doing lots of Java development. Occasionally I have to develop Java in a Windows VM; for this I need fast VMs. I read a lot about SSD wear and maybe it is a bad idea to put the Eclipse workspace on the SSD, because of all the little writes the builds do. Perhaps the workspace (and thus /home) might find a better place on the Velociraptor which is real fast.

How should I partition the whole thing to get the most out of it? I am open to any suggestions. LVM might be an option, too. Maybe putting a third partition on the SSD for one VirtualBox image would be a good idea.

Currently I am thinking:

  • SSD: 2GB /boot, remaining space for /
  • Velociraptor: LVM spanning the whole drive.
    • 150GB /home
    • Remaining Space for /virtualMachines or something like that
  • Samsung drives (LVM over both or one Volume Group for each? - Latter would be better in terms of data security, because if one drive in a big volume group fails everything is lost)
    • Partitions for data, archive, etc
link|improve this question
feedback

2 Answers

up vote 0 down vote

SSD is not reliable as HDD, better use it as temp/page/scratch files, instead of boot. Since you have Velociraptor, SSD is not necessary.

At office I use SSD for my primary disk and develop C# applications on Windows XP, Visual Studio quickly builds and runs to debug my projects. I also use SSD on Hyper-V environment as page/swap/temp files to take HDD a breathe. If you need higher performance, use eBoostr to cache mostly used files, it also decreases the HDD usage, especially on a web server.

link|improve this answer
1  
I don't agree with the first paragraph. Decent SSDs, like the Vertex 3, are significantly faster than VelociRaptor drives. For example, look at the difference in access times here. It's a bit of a waste to not use an SSD as the boot/OS drive. – sblair Aug 21 '11 at 15:41
1  
Yes, but it's not doubles the speed in practice. My SSD has gone. A friend of mine has SSD, it has gone. I just searched for SSD reliability; %2 -or 20?- of them fail. If you use it, backup the partition regularly. Better use Raptor as primary and use eBooster to cache files on SSD. – Nime Cloud Aug 21 '11 at 15:46
An SSD won't double speeds, it'll increase random read/write speeds by nearly an order of magnitude. It's a noticeable difference. Yes, the SSD controllers can sometimes fail (some recent data show about 0.5% to 3% failure rate) and in the long term the flash memory will wear out. But it's worth it. – sblair Aug 21 '11 at 23:28
feedback
up vote 0 down vote

There is another option if the reliability, wear-leveling, and difference between write speed and read speed is of concern:

I have an Acard 9010 battery-backed RAM drive that I run Linux from. It will cost more to populate than the cost of the average SSD, but you get some advantages:

  • Fast read speeds AND fast write speeds. SSDs have really fast read speeds and somewhat less faster write speeds.
  • No wear leveling is needed.
  • No concerns about full disks writing slower than empty ones as exists on SSD's
  • Power blips are covered by the internal battery for about a day, and you can also use the external wall-wart for powering the ram-drive (in addition to the internal backup battery).
  • Longer than battery life storage of your data is solved by the SD card built into the unit: once power is off, and battery voltage gets to a certain low level, the RAM-Drive backs up the contents of memory to a 64 GB compact flash card that is built-in to the front of the ram drive, then on power up, it copies the SD card data back to the Ram in the ram drive.

To directly answer part of the question, how to arrange partitions on an SSD (or RAM drive):

I put everything except /home on the ram drive. /home goes on a hard drive. It takes about 5 GB for Slackware64, so out of a 32 GB RAM drive, I have lots of extra space for development.

You do not have to do your work in /home, though that is the normal "linux way", instead think about creating a directory in the Linux tree like /java or /projects which would be on your ram drive, setting permissions and ownership so your user will be able to use that directory and put your projects on the SSD/RAM drive for speed. Put your OS/tools/source code onto the RAM drive, work there, then have a shutdown script that copies your daily work to the hard drive.

As a belt-and-suspenders measure, I wrote a couple of simple scripts that back up the important user-created files that are on the RAM drive (or SSD) in case of trouble. Files like your /etc/fstab and /etc/X11/xorg.conf that might be troublesome to get exactly right quickly (specially if you have a bunch of mp3 players in fstab, or a complicated monitor setup in xorg.conf, etc., in those files), if you had problems with SSD/RAM getting scrambled at any point.

I also have a pair of scripts that backup/restore every single file on the ram drive to a directory back on a hard drive, just in case. I mention those scripts because another answer mentioned the reliability issues with SSDs (or RAM drives). The scripts give me an extra measure of backup and easy recovery, should things go wrong at some point. Set up a chron job to backup several times a day if you wish, not a bad idea anyway.

So what I do:

  • / on the SSD
  • /work (/java or /projects or other) for your work area, on the SSD
  • /home on a hard drive
  • /usr/scripts (created for user made scripts)
  • scripts to backup user config files from SSD to hard drive
  • scripts to completely copy the RAM drive to a hard drive.

The RAM drive has a .01 ms access time according to their website. It is much faster than a HD but not double (as someone said earlier).

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

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