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-next>] [day] [month] [year] [list]
Date:	Mon, 31 Aug 2009 14:57:02 -0700 (PDT)
From:	Daniel J Blueman <daniel.blueman@...il.com>
To:	Fernando Silveira <fsilveira@...il.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: I/O and pdflush

On Jul 11, 6:30 pm, Fernando Silveira <fsilve...@...il.com> wrote:
> The problem is that after some time of data writing at 70MB/s, it
> eventually falls down to about 25MB/s and does not get up again until
> a loooong time has passed (from 1 to 30 minutes). This happens much
> more often when "vm.dirty_*" settings are default (30 secs to expire,
> 5 secs for writeback, 10% and 40% for background and normal ratio),
> and when I set them to 1 second or even 0, the problem happens much
> less often and the sticking period of 25MB/s is much lower.
[snip]

Generally, this sounds symptomatic of the (now well-documented)
internal block management of the SSD delaying writes significantly
over long use periods - the output from eg 'vmstat 3' will show all
the time spent in I/O wait of course.

In your case, the OCZ Core v2 SSD uses the famed JMicron JMF602 which
chokes up with outstanding write requests, destroying latency and
throughput with it. OCZ won't be releasing newer firmware for the Core
v2, so one last-ditch option is to install the newer stock (non-OCZ
validated, thus invalidating the warranty) JMicron firmware, which
alleviates this somewhat. I've found this successful, though it's
tricky to find!

One other idea is to ensure the filesystem starts on an (at least)
128KB boundary, so as to submit complete erase blocks (usually 128KB).

Thanks,
  Daniel
--
Daniel J Blueman
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ