Go back to the article and read the very first sentence.
Originally Posted by RealNC
I don't think any CF cards expose TRIM at all. The CF interface is the IDE interface, all the flash magic is inside the card.
Originally Posted by adiso
These weren't done by Phoronix. I can't just take anonymous benchmarks without any context seriously :-/
Originally Posted by GreatEmerald
As for CF devices...
There are a few flash file systems like YAFFS and JFFS that will replicate some of what advance controllers like sandforce do for SATA SSD drives.
Yes, but you can only use those on raw flash*. CF just doesn't expose that.
Originally Posted by WorBlux
* Yes, mtd-block can be used to emulate. But that loses any and all advantages.
That's more like it!
One thing is clear with these tests: BlogBench isn't to be taken seriously. Unless someone can explain why IDE mode performs about 35% better with IDE mode on that test.
What's the technical difference between IDE and AHCI modes when using SATA drives? Except for NCQ and hot-swap there must be other differences right? Shouldn't the maximum transfer rate be limited to 133MB/s if this was a real IDE mode?
Re: Why test with SSDs instead of HDs?
Because back when you could still get the same disk in an IDE and SATA model, they usually did not even max the 133MB/sec IDE. Also, the actually delay of physically moving disk heads around dominated the benchmarks then.
Re: Turning off swap. Do it. Linux does go to hell if your virtual memory (RAM+swap) runs out (and has since 1.0 kernel...), but with 8GB that is just not real likely. You've got like 6GB acting as a disk cache at that point which is sweet. If you ever DO need swap space for something or other (and no longer have a swap partition), a swap file is easy to make on the fly. You make an empty file with dd, you run mkswap on it, then run swapon on the swap file. swapoff -a when you are done and you can delete the swap if you wish. If you want it to be more permanent then put it in /etc/fstab.
I was just gonna ask what the heck is up with BlogBench? If a device reads faster, writes faster, and seeks better with AHCI, then why would it be worse in one benchmark? My speculation is blog code tends to be bloated, AHCI lets more blog processes fire up at once then the box gets especially CPU bound (like with make -j, it's faster to run a sane number of copies of gcc than running like -j50.)
Man though, those I/O speeds are amazing 8-).
Nope. Don't do it. Swap is not "more RAM on disk". This is quite an enlightening read:
Originally Posted by hwertz
And about the vm.swappiness sysctl parameter: