Messages in this thread | | | Date | Mon, 31 Aug 2009 14:57:02 -0700 (PDT) | Subject | Re: I/O and pdflush | From | Daniel J Blueman <> |
| |
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!
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |