[NTLUG:Discuss] Re: Can swap be on RAID?

[Greg E]

cbbrowne at godel.brownes.org wrote:
> 


[snip]


> >
> > Other than reducing the need to control pathing to files how can RAID
> > improve performance over a SCSI chain?  If I'm running a chain of 5
> > SCSI drives my disk accesses would be parallel even without RAID so
> > what would RAID buy me?
> 
> If you have a separate filesystem (let's say) on each of those 5
> drives, and access one at a time, then there's no multiprocessing.
> 
> The only way, with 5 filesystems, that you get multiprocessing (e.g. -
> keep those 5 disk controllers busy searching for data) is if you have
> requests going to all of them at once.
> 
> What RAID buys you is the ability to have a single filesystem cross
> over to all 5 physical disks.  A common way to do this is via
> "striping," where a mapping is done that has adjacent sectors from the
> "logical partition" point of view be mapped in sequence to the various
> physical partitions on the five drives.
> 
> Thus, if you request "blocks" 1, 2, 3, 4, and 5 on the logical
> partition, this gets turned into requests, respectively, for block #1
> on each of the physical disks.  Logical block #6 is block #2 on disk
> 1, and similarly Logical #7-10 are block #2 on the respective disks.
> 
> The effect of this is to "fragment" the requests so that they are
> fairly evenly interspersed across the five disks.
> 
> Thus, accesses to the single "logical" partition are turned into
> accesses to 5 disks, which fills up five disks' queues with requests.
> No need to program applications specially; simply by the way the data
> is organized, all the disks will get used.
> 
> There is a cost in doing that mapping of logical "blocks" to physical
> "blocks."  One would expect it to be made up for by the fact that all
> the disks can be searching for data simultaneously.
> 
> --


Agreed that RAID would produce gains for large reads/writes when a
single thread of disk access, even across multiple disks, is done by
a single process on a monolithic task OS.  However we are not operating
on a monolithic task OS.  One of the beauties of a concurrent OS is that
while 1 task waits for I/O another task can issue a completely different
request.

The reason I ask where the gain is in RAID over just setting up
partitions on a SCSI chain is the nature of data access.  I can agree if
all your read/writes are greater than a track in size and you have a
single process funneling all of your requests such that access is done
purely single threaded.  If your accesses come from 3 different processes
and the data for each resides on a different physical device and say each
access is greater than a track in size (contiguous) and each of these
accesses involved data that was not phyiscally in adjacent tracks.  Making
the same request on RAID as SCSI would result in slower results on RAID.
The reason I say this is that the RAID access would require accessing
each disk and queueing the different task requests.  Yes a single access
can be multiprocessed (assuming SCSI) to get the data that spans drives
but the next access would have to wait for the drive to complete before
the head is available to begin the next request.  On the normal SCSI
chain, since the data is located on different disks, all 3 requests can 
be completed in parallel (multiprocessed) because the device is not busy
on another task's request.

As far as managing SCSI partitions simply use links from your IDE.  I can
see where extending your disk full issues can have advantages but you
still need a disk full recovery scheme.  I can also see the advantages of
adding more drive on the fly can help your disk full recovery without
having to mess with your running apps.  So yes I can see many advantages
with RAID from an admin point of view, just not from a performance point
of view.

Greg E