linux-kernel - Re: Debugging system freezes on filesystem writes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130226231703.GA22674@quack.suse.cz>
Date:	Wed, 27 Feb 2013 00:17:03 +0100
From:	Jan Kara <jack@...e.cz>
To:	Marcus Sundman <marcus@...ox.fi>
Cc:	Theodore Ts'o <tytso@....edu>, Dave Chinner <david@...morbit.com>,
	Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: Debugging system freezes on filesystem writes

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@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/