All of lore.kernel.org
 help / color / mirror / Atom feed
* Read-Balancing
@ 2004-02-01  1:47 Corey McGuire
  2004-02-02  4:56 ` Read-Balancing Neil Brown
  0 siblings, 1 reply; 2+ messages in thread
From: Corey McGuire @ 2004-02-01  1:47 UTC (permalink / raw)
  To: linux-raid

Hey folks,

Quick question.

I have been reading up on read-balancing, and I understand that 2.6 has been tuned to have the drive head closest to the data perform the read to reduce seak times. This is neat, but can it prevent two disks from working together to read the same, nonfragmented file?  Did read-balancing ever allow the ability for mirrored drives to work together on a sequential read?  Seams that in a large read, each drive in a mirror could pick up a piece to read, and then reassembled the sequential read in RAM.

Also, does this prevent balancing multiple separate reads in the same file, or will the idle disk seak and read while the drive closer to the action is busy?  Assuming, of course, the data isn't in cache.

Just therory stuff, really, but a curiosity none the less.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Read-Balancing
  2004-02-01  1:47 Read-Balancing Corey McGuire
@ 2004-02-02  4:56 ` Neil Brown
  0 siblings, 0 replies; 2+ messages in thread
From: Neil Brown @ 2004-02-02  4:56 UTC (permalink / raw)
  To: Corey McGuire; +Cc: linux-raid

On Saturday January 31, coreyfro@coreyfro.com wrote:
> Hey folks,
> 
> Quick question.
> 
> I have been reading up on read-balancing, and I understand that 2.6
> has been tuned to have the drive head closest to the data perform
> the read to reduce seak times. This is neat, but can it prevent two
> disks from working together to read the same, nonfragmented file?
> Did read-balancing ever allow the ability for mirrored drives to
> work together on a sequential read?  Seams that in a large read,
> each drive in a mirror could pick up a piece to read, and then
> reassembled the sequential read in RAM. 

It is not trivial to get the two drives to work together on a single
large read.
To get any performance value, you would either need to align the
read request with tracks (you read that track, I read the next track,
and so on) which is not really possible with modern drives, or you
would need each drive to read several tracks.
I'm not sure how big a track is on modern drives, but I suspect it is
several 10s of Kilobytes.  So you you probably need a 100K read on
each drive before you could see any benefit.

There is code in 2.4 to limit each drive to 128 sectors (64k) before
it must try a different drive.  This code seems to have
disappeared from 2.6.
I have no idea if it ever did anything useful.
If you are really interested you could try doing some speed testing to
see if you could demonstrate a improvement in throughput by
alternating requests between two drives.

NeilBrown


> 
> Also, does this prevent balancing multiple separate reads in the same file, or will the idle disk seak and read while the drive closer to the action is busy?  Assuming, of course, the data isn't in cache.
> 
> Just therory stuff, really, but a curiosity none the less.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-02-02  4:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-01  1:47 Read-Balancing Corey McGuire
2004-02-02  4:56 ` Read-Balancing Neil Brown

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.