On Thu, 5 Apr 2007, Justin Piszcz wrote:
On Thu, 5 Apr 2007, Iustin Pop wrote:
On Wed, Apr 04, 2007 at 07:11:50PM -0400, Bill Davidsen wrote:
You are correct, but I think if an optimization were to be done, some
balance between the read time, seek time, and read size could be done.
Using
On Mon, Apr 09, 2007 at 06:53:26AM -0400, Justin Piszcz wrote:
Using 2 threads made no difference either.
It was not until I did 3 simultaneous copies that I saw 110-130MB/s
through vmstat 1, until then, it only used one drive, even with two cp's,
how come it needs to be three or more?
On Wed, Apr 04, 2007 at 07:11:50PM -0400, Bill Davidsen wrote:
You are correct, but I think if an optimization were to be done, some
balance between the read time, seek time, and read size could be done.
Using more than one drive only makes sense when the read transfer time is
significantly
On Thu, 5 Apr 2007, Iustin Pop wrote:
On Wed, Apr 04, 2007 at 07:11:50PM -0400, Bill Davidsen wrote:
You are correct, but I think if an optimization were to be done, some
balance between the read time, seek time, and read size could be done.
Using more than one drive only makes sense when
Iustin Pop wrote:
On Wed, Apr 04, 2007 at 07:11:50PM -0400, Bill Davidsen wrote:
You are correct, but I think if an optimization were to be done, some
balance between the read time, seek time, and read size could be done.
Using more than one drive only makes sense when the read transfer
On Thu, Apr 05, 2007 at 04:11:35AM -0400, Justin Piszcz wrote:
On Thu, 5 Apr 2007, Iustin Pop wrote:
On Wed, Apr 04, 2007 at 07:11:50PM -0400, Bill Davidsen wrote:
You are correct, but I think if an optimization were to be done, some
balance between the read time, seek time, and read
On Thu, 5 Apr 2007, Iustin Pop wrote:
On Thu, Apr 05, 2007 at 04:11:35AM -0400, Justin Piszcz wrote:
On Thu, 5 Apr 2007, Iustin Pop wrote:
On Wed, Apr 04, 2007 at 07:11:50PM -0400, Bill Davidsen wrote:
You are correct, but I think if an optimization were to be done, some
balance between
Justin Piszcz wrote:
On Thu, 5 Apr 2007, Iustin Pop wrote:
On Thu, Apr 05, 2007 at 04:11:35AM -0400, Justin Piszcz wrote:
On Thu, 5 Apr 2007, Iustin Pop wrote:
On Wed, Apr 04, 2007 at 07:11:50PM -0400, Bill Davidsen wrote:
You are correct, but I think if an optimization were to be
Al Boldi wrote:
Bill Davidsen wrote:
Al Boldi wrote:
The problem is that raid1 one doesn't do striped reads, but rather uses
read-balancing per proc. Try your test with parallel reads; it should
be faster.
:
:
It would be nice if reads larger than some size were considered
Bill Davidsen wrote:
Al Boldi wrote:
The problem is that raid1 one doesn't do striped reads, but rather uses
read-balancing per proc. Try your test with parallel reads; it should
be faster.
:
:
It would be nice if reads larger than some size were considered as
candidates for multiple
Hello list,
normally, I'd think that combining drives into a raid1 array would give
me at least a little improvement in read speed. In my setup however,
this does not seem to be the case.
14:16 opteron:/var/log # hdparm -t /dev/sda
Timing buffered disk reads: 170 MB in 3.01 seconds =
Jan Engelhardt wrote:
normally, I'd think that combining drives into a raid1 array would give
me at least a little improvement in read speed. In my setup however,
this does not seem to be the case.
14:16 opteron:/var/log # hdparm -t /dev/sda
Timing buffered disk reads: 170 MB in 3.01
On Sun, 2007-04-01 at 14:19 +0200, Jan Engelhardt wrote:
Hello list,
normally, I'd think that combining drives into a raid1 array would give
me at least a little improvement in read speed. In my setup however,
this does not seem to be the case.
14:16 opteron:/var/log # hdparm -t
13 matches
Mail list logo
