Swap space doesn't use a filesystem at all. For regular filesystem partitions, my thoughts are:
- Ext2fs -- This is the major surviving non-journaled Linux-native filesystem, and as such it has limited utility. I'd only recommend it on a small partition (such as a separate
/boot
partition or possibly a small USB flash drive), where the journal will be more of a detriment than an advantage.
- Ext3fs -- This is ext2fs plus a journal, which reduces disk-check times after a power failure or system crash. Ext3fs used to be a decent choice, but it's been pretty well eclipsed by ext4fs these days....
- Ext4fs -- This is ext3fs plus some new features that improve performance and enable use on larger disks. It's probably the best general-purpose filesystem for Linux these days; certainly it's the one that most distributions favor by default.
- ReiserFS -- This filesystem is roughly comparable to ext3fs in features. Its main standout point is that it's especially good at handling small files (as in a few kilobytes, or even under a kilobyte). If you happen to be storing lots of dinky files, it's still worth considering. OTOH, it's not a "hot" filesystem, so development is slow, and ReiserFS lacks the advanced features found in ext4fs and the later filesystems on this list. A variant, Reiser4, promises such features but has been very slow in materializing as an actual in-kernel filesystem. I'm not holding my breath on Reiser4 becoming viable.
- XFS -- Favored by system administrators on big disks (over a few terabytes), XFS has some moderately advanced features, and has a good reputation for handling large files. XFS partitions can't be shrunk, though, which can be a problem if you're not sure how big to make your partitions.
- JFS -- Similar in many ways to XFS, JFS has never been as popular. A few years ago, it wasn't as reliable, but I'm not sure that's the case any more. I can't think of any good reasons to favor it today on a Linux-only system, although there may be some specialized cases where it would perform better than other filesystems.
- Btrfs -- This is the newest Linux-native filesystem, and it includes advanced features like the ability to span a filesystem across multiple disks and to take snapshots. It's still experimental, though, so it's not really recommended for use in production environments.
ph0t0nix mentioned ZFS, but that's not really Linux-native. (It was developed by Sun, and has been ported to some of the BSDs, but licensing issues prevent moving that code into the Linux kernel.) There are two ZFS implementations for Linux, one of which can be built into the kernel and the other of which is a userspace driver accessed via FUSE. The kernel ZFS driver isn't part of the standard Linux kernel, though, which is a big drawback in my view; IMHO, a driver for your main filesystem should be a standard part of the kernel, not an add-on package that might not work if you upgrade your kernel.
Overall, then, and IMHO, the best general-purpose options at the moment are ext4fs and XFS. Of the two, I give the nod to ext4fs because it's more popular and it can be shrunk. Ext2fs is OK on small partitions (say, under 1GB or so), ReiserFS can be good if you store lots of very small files, and Btrfs is good if you need advanced bleeding-edge features and don't mind the risk. I don't happen to have benchmark data handy on these filesystems, and such data can be difficult to interpret because so many factors can influence performance (disk type, file sizes, system load, etc.). You could try looking up such data if speed or system load is particularly important to you.
There are of course non-native filesystems, too -- NTFS, FAT, HFS+, etc. You can't use these as the filesystem for your main Linux installation. (I suppose you might be able to use HFS+ for that purpose, but I've never tried it, and it certainly isn't supported by the Ubuntu installer!) You'd use these for interoperability on dual-boot computers or on removable disks.
The first question I'd be asking is Can the SSD be trusted as a primary drive? This was built to be a a cache drive and cache data is usually a copy of something stored elsewhere. There's no need for that data to have any integrity. Invalid data? Just rebuild off the main storage. To use it as primary storage might not be a great idea because corruption there is permanent.
Next, Does it perform well? Cache SSDs are cheap patches to plug the hole that is the incredibly slow magnetic disk that laptops get. If it's unbranded (and there are no specs on the internet), give it a quick spin with the Disk Utility in a Live CD/USB
If the answer to these two is anything but "it's fine, it's a solid disk", I'd look at replacing it with a better mSATA (I assume that's the connection but check first!) SSD. Even ~60GB ones aren't that expensive and you can be a little more assured that they're not going to die on their first outing as a primary disk.
Where you plop your partitions is largely going to depend on how you use your system. I don't know how much user content you have versus installed applications.
For what it's worth, with a 120GB SSD, I have / and /home on SSD with things symlinked and bind-mounted over to RAID5 and RAID1 and NFS. Steam allows you to store things on other media so that handles itself quite nicely. And I occasionally manually copy things to SSD for speed and symlink them.
... But I have the space to make that possible. 24GB is really restrictive. I don't think that approach is going to work well for you.
You're not mentioning another option: Throw the crappy 5400RPM laptop drive into the ocean and buy a better SSD to replace it and use network storage for all the data you hold dear.
Laptops are awful permanent storage because they get stolen, lost and dropped. It might make sense to have a centralised NFS NAS where you keep all the important stuff.
Best Answer
Swap should be on hard drive. With 12GB of RAM you may never use swap. The only time you might use swap would be if you hibernate, but if booting from SSD hibernation does not save much if anything. I still suggest a little swap just to have some or maybe 2GB. Others have had no swap with that much RAM and said it works.
You need to change to AHCI and removed RAID meta-data on drives. That is probably why grub will not install as it sees the RAID and wants to install to RAID.
Is system UEFI or BIOS? That makes a difference on where to install grub. If BIOS you install grub to the MBR of either drive, but preferred to install to SSD. If UEFI you install to efi partition.
If you use manual install and have already created partitions with gparted, you just need to select partition for / (root), choose format and what format (ext4 usually), likewise for /home but if /home already exists with data you DO NOT format. If swap already exists it will find it automatically.
I have a 28GB /(root) partition and use about 9GB including /home which has .wine with Picasa. I have lots of programs installed. I think you can installs games to /home so those would be on HDD. You can split system folders and add to HDD like you do with /home but that should not be required.
All system folders in / can be partitions. Usually only done for servers with specific requirements.
Explanation of file structure
http://www.tuxfiles.org/linuxhelp/linuxdir.html
http://www.pathname.com/fhs/pub/fhs-2.3.html
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
http://en.wikipedia.org/wiki/Linux_Standard_Base
http://en.wikipedia.org/wiki/Unix_directory_structure