On Tue 26-02-13 20:41:36, Marcus Sundman wrote:On 24.02.2013 03:20, Theodore Ts'o wrote:As Ted wrote, alignment isn't usually a problem with SSDs. And even if itOn Sun, Feb 24, 2013 at 11:12:22AM +1100, Dave Chinner wrote:OK. Removing 'discard' made it much better (the 60-600 secondLooks like the Sandisk U100 is a good SSD for me to put on my personal^^^^^^^/dev/sda6 /home ext4 rw,noatime,discard 0 0
I'd say that's your problem....
"avoid" list:
http://thessdreview.com/our-reviews/asus-zenbook-ssd-review-not-necessarily-sandforce-driven-shows-significant-speed-bump/
There are a number of SSD's which do not implement "trim" efficiently,
so these days, the recommended way to use trim is to run the "fstrim"
command out of crontab.
freezes are now 1-50 second freezes), but it's still at least an
order of magnitude worse than a normal HD. When writing, that is --
reading is very fast (when there's no writing going on).
So, after reading up a bit on this trimming I'm thinking maybe my
filesystem's block sizes don't match up with my SSD's blocks (or
whatever its write unit is called). Then writing a FS block would
always write to multiple SSD blocks, causing multiple
read-erase-write sequences, right? So how can I check this, and how
can I make the FS blocks match the SSD blocks?
was, it would be at most a factor 2 slow down and we don't seem to be at
that fine grained level :)
At this point you might try mounting the fs with nobarrier mount option (I
know you tried that before but without discard the difference could be more
visible), switching IO scheduler to CFQ (for crappy SSDs it actually isn't
a bad choice), and we'll see how much we can squeeze out of your drive...