If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

OCZ Agility EX 60GB SSD

Phoronix: OCZ Agility EX 60GB SSD

Back in August we reviewed the OCZ Agility SATA 2.0 SSD, which we found to be a reputable solid-state drive that offered nice performance under Linux. However, a step up from the Agility series is the Agility EX line. The OCZ Agility EX is designed to offer maximum performance with its SLC NAND-based storage and Indilinx controller. How though does the performance of this $400 SSD for just 60GB of storage compare to their other MLC-based SSDs under Linux? We have the benchmarks.

The key issue with all SSDs is the stuttering that starts happening once the disk starts rewriting data over the previously used sectors.

While it is claimed that “..the combination of the Indilinx Barefoot controller, Samsung flash memory, and 64MB of on-board cache delivers blistering, stutter-free performance, eliminating the bottleneck imposed by traditional mechanical hard disks..”, I would really like to see this in a real life sittuation.

Are there any specific disk test profiles in the PTS that would test this stutter issue?

The key issue with all SSDs is the stuttering that starts happening once the disk starts rewriting data over the previously used sectors.

While it is claimed that “..the combination of the Indilinx Barefoot controller, Samsung flash memory, and 64MB of on-board cache delivers blistering, stutter-free performance, eliminating the bottleneck imposed by traditional mechanical hard disks..”, I would really like to see this in a real life sittuation.

Are there any specific disk test profiles in the PTS that would test this stutter issue?

This controller does support the ATA TRIM command (assuming a recent firmware), so it should be a non issue when the fs and os support it.

I'm SSD owner for over a year and half,
But I still can't be sure that my SSD configured properly to give max performance.
The unanswered questions are:
What is the best files system to use. (performance and stability)
What options to use when creating it.
What options to use when mounting it.
What scheduler to use.
What about "TRIM" which supposed to solve performance degradation.

Some how there is no "human readable info" that i could find.
Following some guides I couldn't complete them.
For example, i could not increase block size to 64K (or actually any above)
I'll Be glad to read and even help in creating such manual.

I'm SSD owner for over a year and half,
But I still can't be sure that my SSD configured properly to give max performance.
The unanswered questions are:
What is the best files system to use. (performance and stability)
What options to use when creating it.
What options to use when mounting it.
What scheduler to use.
What about "TRIM" which supposed to solve performance degradation.

Some how there is no "human readable info" that i could find.
Following some guides I couldn't complete them.
For example, i could not increase block size to 64K (or actually any above)
I'll Be glad to read and even help in creating such manual.

I would recommend ext4 as filesystem.It does send discard requests to the block layer (which sends the ATA TRIM command to the drive) brtfs works too, but it is not ready for general use yet-

Creating the fs is a different matter, ideally it should be aligned to the SSD's erase block size, or a multiple of that.

For that I recommend 512 if because it works for any SSD.
To do this you have to create the partitions using fdisk.

fdisk -H 32 -S 32 /dev/yourssd
When creating the first partition use 2 as starting sector.

After that you can create the file system. When using mkfs.ext4 you do not want/should set the blocksize to 64k but you should do the following:

-E stripe-size=128

This would result into a stripe-size of 4*128 (assuming block size stays at 4 which is the default).

As for mounting it I would just pass "noatime", it causes unnecessary write accesses that might hurt your SSDs life time.

Some people recommend not using a journal, but if you care about your data don't do that.

I would recommend ext4 as filesystem.It does send discard requests to the block layer (which sends the ATA TRIM command to the drive) brtfs works too, but it is not ready for general use yet-

Creating the fs is a different matter, ideally it should be aligned to the SSD's erase block size, or a multiple of that.

For that I recommend 512 if because it works for any SSD.
To do this you have to create the partitions using fdisk.

fdisk -H 32 -S 32 /dev/yourssd
When creating the first partition use 2 as starting sector.

After that you can create the file system. When using mkfs.ext4 you do not want/should set the blocksize to 64k but you should do the following:

-E stripe-size=128

This would result into a stripe-size of 4*128 (assuming block size stays at 4 which is the default).

As for mounting it I would just pass "noatime", it causes unnecessary write accesses that might hurt your SSDs life time.

Some people recommend not using a journal, but if you care about your data don't do that.

I hope this answers your questions.

Kind off
it is pretty similar to what i found here:http://blogs.gentoo.org/nightmorph/2...systems-part-2
And herehttp://thunk.org/tytso/blog/category/computers/ssd/
They suggest 4K alignment (and somehow, intuitively i tend to agree)
Anyway the question about TRIM is not completely answered in my case.
My SSD is the old dumb one. without firmware upgrades. So it does not support this command. The question is partially answered in the second link blog post. But not optimistically
My suggestion was to do 2 things:
1. To do research on FS + SSD (which i would help) which will examine dumb and smart SSD's behavior coupled with few promising file systems with different mount options. It will be very time consuming, so i'm ready to volunteer to do what i can.
2. To use conclusions of this study to write comprehensive guide.
May be this data would be used by distributions like Sabayon, Ubuntu, OpenSUSE, Fedora and other to make better installations.

unfortunately it was not possible to install aio-stress and dbench. These would have been the most interesting tests i think.

[RESULT 2]
wiper.sh + DiskTRIM
when trimming procedure was executed iozone got "no space left on device". But as you can see. trimming will speed up your ssd. It has to be part of the kernel! while you do massive file operations, e.g copying a film collection; Trimming cant be used, because of "no space left On device" errors. After your trimming procedure has finished, space is available again...