[lug] software RAID

Sean Reifschneider jafo at tummy.com
Mon Feb 13 02:13:40 MST 2006


On Sat, Feb 11, 2006 at 04:56:44PM -0500, Dean Brissinger wrote:
>until you copy a file from the system drive to the zip drive.  At which
>point the system will a) need swap, b) need dedicated i/o to the hdd for
>read, and c) need dedicated i/o to the zip.  The controller will refuse
>two and the end result is a deadlock after one or two (lucky) cached

Not quite.  Reads or writes that can't be satisfied right away don't block
anything else from happening.  Linux will handle reading from the source
when the bus is available, and writing to the destination when data is
available for it.

Obviously, the destination can't write data that the system hasn't read
off the source.  So if the destination device has the bus, you are writing
data, depleting the data you have from the source device.  Once the data
to write has been exhausted, the bus will be free for doing more reads.

This is kind of the high-level of what's happening.  The details really
depend on what the lower-level IO scheduler is doing.  If it gives priority
to reads it could wait for the current write request to complete and then
do another read.  I want to say that Linux gives priority to writes though,
so it's kind of the inverse.

It also depends on what you have the pre-fetch value for the source device
set to as well, and whether you are reading large files or small (pre-fetch
mostly helps large files).

Of course, it's quite different under SATA where some controllers and
devices support more advance SCSI things like native command queueing...

Thanks,
Sean
-- 
 Electricity travels a foot in a nanosecond.
                 -- Commodore Grace Murray Hopper
Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability




More information about the LUG mailing list