Re: I/O and pdflush

[Fernando Silveira <fsilveira@gmail.com>]

On Mon, Aug 31, 2009 at 18:57, Daniel J Blueman<daniel.blueman@gmail.com> wrote:
> On Jul 11, 6:30 pm, Fernando Silveira <fsilve...@gmail.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@gmail.com>