Geoff Steckel [g...@oat.com] wrote:
> I didn't follow the thread all the way back, so forgive me if this has
> been covered. I'm betting that the disk subsystem & RAID controller
> combination are choking on queued metadata writes. Some of the questions
> are aimed at the user, and some at people w
On 01/11/2012 05:12 PM, Ted Unangst wrote:
On Wed, Jan 11, 2012, Chris Cappuccio wrote:
If only one disk is affected at a time, 5.0 is the fastest, and has the
most trouble with responsiveness while being fast, this is likely to be
improved by a fair I/O scheduler. There is a generic framework
Ted Unangst [t...@tedunangst.com] wrote:
> On Wed, Jan 11, 2012, Chris Cappuccio wrote:
>
> > There's also an issue with dirty buffers getting eaten up, but that is
> > prominent on slow devices, and you'd be WAITing in buf_needva in that case.
>
> I don't think needva has been totally ruled out
On Wed, Jan 11, 2012, Chris Cappuccio wrote:
> If only one disk is affected at a time, 5.0 is the fastest, and has the
> most trouble with responsiveness while being fast, this is likely to be
> improved by a fair I/O scheduler. There is a generic framework in place
> now for schedulers to get plu
I think your report falls a little short on explaining the problem. It's cool
to see the benchmarks improve in 5.0. But "Remarks: Terribly slow!" is all you
provide to explain the problem in the same 5.0
It would be better to have another test that represents the problem along with
each dd test
I've installed OpenBSD onto this box from 4.6 through 5.0 to compare wait
times for simple operations. I don't expect miracles from this relatively
cheap raid controller, but, I expect it to be at least as quick as a regular
sata drive!
So, I'm dd'ing 10GB of zeros to a file, sleeping for a second
Both the writing process and anything else I try to do at the same time have
biowait. top itself takes several seconds to start up before I can see any
output.
On 10 Jan 2012, at 01:48, Chris Cappuccio wrote:
> George Steel [li...@netglue.co] wrote:
>>
>> When writing to the disk(s), the whole sy
George Steel [li...@netglue.co] wrote:
>
> When writing to the disk(s), the whole system becomes incredibly slow
> until the write operation has finished. I've used dd to make 10GB files
> and then timed simple operations like ls and compared this to other
> OpenBSD servers I've got with single SA
8 matches
Mail list logo
