linux-ext4 - Re: very slow SSD with fsync

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 13 Mar 2015 11:25:59 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Adrian Bridgett <adrian@...p.co.uk>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: very slow SSD with fsync

On Fri, Mar 13, 2015 at 02:48:03PM +0000, Adrian Bridgett wrote:
> Slow as in sync(1) taking 6 seconds on an idle system, dd-ing from the raw
> disk drops from 600MB/s to less than 1MB/s.   iotop shows jbd2 often waiting
> a long time, but _very_ low throughput (KB/s it that).  I've spent a day or
> so trying everything I can find to identify the cause but I'm completely
> stuck (even with help from a btrfs guru - he eventually suggested asking
> here).

The obvious thing to do is to try using blktrace to see which I/O
operations are triggering the problem.  It may just be that the hard
drive's internal FTL metadata is very badly fragmented.

If so, it could be that that the only thing that will fix things is to
reset the entire FTL is to do a full backup, do a discard or a secure
erase on the entire SSD, and then reformat and do a restore from
backups.

You might also try looking at the SSD model and try to find some
reviews on Tom's Hardware or Anand Tech to see how the SSD fares when
stressed on various SSD torture tests.  What model SSD is it, by the
way?

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html