linux-kernel - Re: I/O and pdflush

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] [day] [month] [year] [list]

Date:	Tue, 1 Sep 2009 11:33:55 -0300
From:	Fernando Silveira <fsilveira@...il.com>
To:	Daniel J Blueman <daniel.blueman@...il.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: I/O and pdflush

On Mon, Aug 31, 2009 at 18:57, Daniel J Blueman<daniel.blueman@...il.com> wrote:
> 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!

Thanks, I'll keep that in mind. If no other safer solution else helps,
I'll update the JMicron.

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

I don't use any kind of filesystem, just plain sequential data dump. I
can change the block size for each write(2), but I'm already using a
huge one: 4MB. I tried lower and higher values before but it seems
that the 70~80MB/s rate is only reached with blocks of 1MB or bigger.

-- 
Fernando Silveira <fsilveira@...il.com>
--
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/