Re: Debugging system freezes on filesystem writes

[Jan Kara <jack@suse.cz>]

On Tue 26-02-13 20:41:36, Marcus Sundman wrote:
> On 24.02.2013 03:20, Theodore Ts'o wrote:
> >On Sun, Feb 24, 2013 at 11:12:22AM +1100, Dave Chinner wrote:
> >>>>/dev/sda6 /home ext4 rw,noatime,discard 0 0
> >>                                    ^^^^^^^
> >>I'd say that's your problem....
> >Looks like the Sandisk U100 is a good SSD for me to put on my personal
> >"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.
> 
> OK. Removing 'discard' made it much better (the 60-600 second
> 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?
  As Ted wrote, alignment isn't usually a problem with SSDs. And even if it
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...

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR