ssd trim in ubuntu?

Hi, I've been using ubuntu netbook remix 9.04 for a little while(I'm still a novice) on my 1810t with no problem but I just bought a intel X-25 V and I'm wondering if I got my trim working right (i'm not 100% sure what it does except boost performance)

I'm sorry if there is a thread that covered the subject I scrolled quickly in the search tab and couldn't find one.

I did some research and I think it only work on ext4 file system and I'm not sure if it's supported on 9.04 so i upgraded to a 9.10 netbook remix (wich caused me more trouble on the ui side then 9.04)

I found some help via google and installed hdparm-9.27 and got a hold of a wiper-2.5 file that support intel ssd.

I then run sudo ./wiper.sh --commit /
in my hdparm folder and I get this

Does this seem like working trim? If so how often should I run this (my guess is its automatic in w7) and what is a good way to test hd performance in ubuntu so I know if it actually works?

Thanks alot for any help I can get

 

http://lwn.net/Articles/353411/

That article might shed some light on things Google for Linux trim instead of Ubuntu... it's more a function of the kernel than anything.

 

I dont know for certain if Ubuntu 9.04 supports ssd trim, but maybe Ubuntu 10.04 LTS will since its based on a newer kernel.

 

I'm fairy sure 9.04 doesn't support ATA Trim. Neither does 9.10.

Linux has full Trim support only since 2.6.32. (According to Wikipedia, Trim was prepared in 2.6.28 but not fully implemented.)

Since 10.04 LTS will use 2.6.32, it should support Trim (it seems some of the necessary changes on the file system side have already been implemented with Karmic).

 

Just a quick update on this: while 2.6.32 supports the ATA TRIM command, it only does so for the btrfs file system. The 2.6.33 kernel released today now also supports it on ext4, nowadays the default file system in many distros.

However, in the standard config, support for TRIM is not activated. Let's hope our favorite distros will enable it nevertheless during the upcoming release cycle.

 

I'm not sure it was in any flavor of 2.6.32, but it's surely in vanilla 2.6.33. This patch came 1 day after .32 was released:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=18f0f97850059303ed73b1f02084f55ca330a80c

 

Well it's not like the OP can't compile it's own kernel right? Unless they have changed the procedure, I'll I had to do was download a tarball, select whatever options I wanted to have on the kernel when creating the makefile, launch the build and go outside while the computer was crunching numbers... It is fairly straightforward.

 

^^^ agreed, if OP doesn't mind grabbing a 2.6.33 vanilla and compiling it, there should be no problem.

i'd be interested to hear if somebody knows more. all i figured is that trim must still be somewhat experimental since it's deactivated by default.

 

Is the TRIM tool restricted to Intel SSDs?

 

No, TRIM is a (mostly) standard ATA command, so any drive that implements it (some need firmware updates, etc) should work given a filesystem (and kernel) that supports it.

 

Just ordered a Kingston SSDnow snv-425 with the revised j micron controller. Not the fastest, but definitely a step up from 5400rpm notebook drive. We'll see how it goes. I think I'll just install Ubuntu 10.04 fresh when it comes out.

Do we still need to "align partitions" on SSDs?

 

Yes you still need to align partitions, TRIM just speeds up writes to previously used space.

Think of how you delete a file and you can still recover it later; it is still on the disk taking up space, it is just gone from the filesystem's records. The SSD sees a block of data and still thinks it is in use, which slows things down. With TRIM the filesystem tells the kernel which tells the controller that a block is no longer in use, and this speeds up writing to the drive.

If you don't align the partitions you are ending up with more read/write/erase cycles than you need to, since the filesystem block size won't match the controller's block size.

The performance difference will vary between controllers, but always will be better when aligned to the erase block size, and even better with TRIM, especially after you use the SSD for a while.

 

Any guides to partition alignment under ubuntu?

 

I went by these directions: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/

I skipped the LVM parts, and only used the fdisk and mke2fs examples as references. It's a lot easier than he describes if you only have one or two partitions.

 

He states that his first partition isn't aligned. But I want my first partition to be / not /boot, so I need it aligned. I like to have separate / and /home partitions.

 

I left my /boot unaligned as my first partition, but if you want only /home and root, leave some free space before the first partition to keep it aligned.

 

Just a quick update on this: while 2.6.32 supports the ATA TRIM command, it only does so for the btrfs file system. The 2.6.33 kernel released today now also supports it on ext4, nowadays the default file system in many distros.

However, in the standard config, support for TRIM is not activated. Let's hope our favorite distros will enable it nevertheless during the upcoming release cycle.

 

My ssdnow has 8kbyte write page size, and 1MB erase page size. How would we align it?

 

Same way as in the guide from Ted Ts'o:

Code:

fdisk -H 224 -S 56 /dev/sdb

As he says, this leaves the first partition unaligned. Create a first partition (or just leave it as empty space), doesn't have to be big, then create your other partitions.

You will need to do this outside of the normal installer I'd suspect, since most installers have automated tools these days for partitioning, and fdisk is generally not an option. You can just hit alt+f2 in the Debian installer to get to a shell and use fdisk, I think you can on Ubuntu as well. Or you can run a livecd. Then when you get to the partitioning step in the installer you can use the manual partitioning option and make sure your mount points are set correctly for the partitions you already created.

 

Less of the first, more or the second - ultimately, it takes a lot of time to "erase" a block in an SSD. Enough time that it's faster to simply write to a new, empty block than to read everything out of a block, and into a buffer, erase that block, merge the stuff you just read out of a block with the new stuff you want to write to the block, then write that block.

In the SSD case, you can think of a "block" as a large chunk of space. The SSD reads and writes data to an entire block at a time, regardless of how much of the block is actually used up. So even if you only use up 25% of the block, you can't fill the next 25% of the block until you do the "Read - Erase - Write" cycle.

The controller "knows" which blocks of data are already "used". So when writing new data, it just moves to the next unused block for much faster performance. What TRIM does is tells the controller to start going through (when it's not doing anything else) and "erasing" the blocks that are marked as "deleted" but still have something in them, thereby "zeroing out" that block, so it's fast to write to for the next time some data has to be written to it.

 

I don't follow you. In a nutshell what I said was: without trim once you fill a critical level of the disk it degrades since you are constantly doing erases before you can write... alignment is a separate issue, which you also quoted but did not address. Again, I don't follow you.