SSD TRIM thoughts Linux, Mac OS X

SSD are more and more a standard thing now-days.
When it comes to windows you have only one solution and it's the seventh version of the Operating System. It is the only one that supports the TRIM command of the SSD drives.

A little background about TRIM: It is the way to keep your SSD in shape. What is does is allows an operating system to inform a solid-state drive which blocks of data are no longer considered in use and can be wiped internally. (wikipedia)

But how about Linux and Mac OSX ?

Linux has support for TRIM in the kernel from version 2.6.33 and after. This means that if you run a newer kernel you automatically has support for TRIM through the kernel and you don't need to do something more.
For previous kernels you can use newer versions of hdparm program or wiper (more information can be found on the web).

How about MacOSX?

According to Apple (here) TRIM support is scheduled to be added in an update of the Operating System. Still you can buy Apple computers with SSD. What does Apple does to the Operating System for avoiding the usage of TRIM so far? According to the bit-tech review (here) MacOSX doesn't really need the TRIM support for now.

Is it possible that what the Apple engineers did to be implemented to other Operating Systems as well? Maybe in Windows is hard to be implemented but in Linux or any other unix-like might be possible.


P.S.: If anyone has an SSD and a Mac OSX and noticed any difference in performance of writes please feel free to share.

noatime + BFS + kernel update = win

Lately my laptop was quite slow in terms of performance
It's an old one with a crappy centrino cpu 1.5Ghz and with only 768 mb of memory.
When I was on debian I used a light desktop environment but since I liked ubuntu user-friendly UI I wanted gnome now.
Still I didn't think memory was the problem when I had almost everything closed and around 500mb of mem free.
So I thought It either IO requests of CPU.
So here are some steps which made my system be a bit more responsive:

1. Probably the easiest is the a mount parameter on the file-system.
   The ext3,4 filesystem has a parameter which for mounting with or without access time enabled.
   atime parameter on mount write the timestamps whenever it is reading the file or directory. This makes another step on the reading of every file on the system. You most probably don't need this unless it mess up with news servers etc. which I don't use.
   Tip: You can use realatime parameter for that on latest kernels.
   
   In order to disable this on mount of an ext3,4 file-system we have to mount with the option of noatime on the system:
   On the fly:
   

   $ sudo mount -o remount,noatime /

   or by editing /etc/fstab and adding the noatime on options field:
   

   /dev/sda1 / ext4 errors=remount-ro,noatime 0 1

2. The second thing you can do is change the Process Scheduler. It's a system responsible for manipulating the processes priorities on the kernel. Latest kernel use the CFS (completely fair scheduler)
   The person (Con Kolivas) who inspired the write of CFS wrote lately another one which called Brain Fuck Scheduler and it's more for desktop computers.
   In order to use the BFS we have to recompile the kernel patched with Con Kolivas' patch
   Info can be found on his page but here is what I did:
   First download a stable kernel for which Colivas have a patch on his site
   I choose 2.6.35 since it said to improve btrfs performance as well
   

   $ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.35.tar.bz2
   $ tar xvfj linux-2.6.35.tar.bz2
   $ cd linux-2.6.35
   

   Now we need to patch it with the colivas patch:
   Download the patch for the kernel version you have from site. For my choice:
   

   $ wget http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.35/2.6.35-ck1/patch-2.6.35-ck1.bz2
   $ bunzip2 patch-2.6.35-ck1.bz2

   And now we have to patch the kernel:
   

   $ patch -p1 < patch-2.6.35-ck1

   
   
   
   
   This will change some files on the kernel source. After that the procedure for kernel compilation is common. Just follow directions from Canonical or kernel.org

All and all took me something like an afternoon to learn all those and to compile the kernel on with my old cpu. After that I found out the localmodconfig option of make kernel in order to save some time. :)
Now I have a 2.6.35 kernel with BFS and I can see a difference in a lot of applications. It is quite more responsive that it used to be.

btrfs raid0 benchmarks

Playing around with btrfs-tools and raid0 i wanted to test myself the results on just SATA drives and not the high-end hhd.

So since I use debian unstable it was easy to get support from btrfs

Latest kernel in debian unstable 2.6.32 supports btrfs so all I needed was the btrfs-tools

# sudo aptitude install btrfs-tools

This should do the trick although n order to be sure I downloaded the latest version from git:

https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories

There are detail info as well for how to compile the tools.
After that following the info from the btrfs wiki I could easily make the file system with multiple devices

# mkfs.btrfs -m raid0 -d raid0 /dev/sdc1 /dev/sdd2 /dev/sde2

 The above command tells the mkfs to make a btrfs filesystem with raid0 on data (-d parameter) and metadata as well (raid0).

Now the mount can be done on any of the devices
I did it on /dev/sdc1 and with compress mount parameter on

# sudo mount /dev/sdc1 -o compress /mnt

Fow the benchmark I used the iozone program

# sudo aptitude install iozone

using only test 0 and 1 which are tests for read and write. The exact command was:

# iozone -s 8g -r 1024 -i 0 -i 1

 The results from the benchmark is as follows:

KB  reclen   write rewrite     read   reread
8388608    1024  135151  139050   233461   235929

That's around 135Mb/sec write speed and 233Mb/sec read speed
Probably topped up from my CPU which in benchmarks hit 100% on both cores.
I suppose if I remove the compress option it would be OK but will lose some speed