linux guy wrote:
>"As you say, if the recordings are on completely separate dives it
>shouldn't be a problem. That may not be practical."
>>Are you saying it would be better if the recordings were each on a
>different drive or the recordings together were on a different drive
>from the NAS ?
The recordings, as a collection, on different drive(s) from those
used for other functions. So that might be just one large drive for
your recordings, and a group of RAIDed drives for everything else.
Clearly it would be impractical to have each recording on it's own
drive !
>Is it better to have drives on their own controller or is it fine to
>have them share one controller and use different channels ?
I believe it would mostly be OK on the same controller as long as
it's of a type where the drives are independent. Eg, on SCSI and IDE
you've got shared busses so it's possible for activity on one drive
to affect access latency on another. But how much this occurs between
separate links (eg SATA) on a common controller will depend to a
large extent on the design of the controller - I'm sure some are
better than others in this respect.
And don't forget that the OS (and it's driver stack) will have it's
own restraints on concurrency - eg if you do something that really
hits one group of disks, that may make requests for other disks take
longer to work through the queue(s). I have no knowledge of the
details on that.
I de recall at a previous job having a system that could be ground to
a virtual standstill by running a report. The OS had a hard coded
limit on disk buffer/cache, and some order details files were
significantly larger than that. The main reporting tool was "not very
clever" and had a tendency to do linear searches instead of using the
indexes - hence it would read an entire file which was larger than
the disk cache. The result was that it a) flushed everything else out
of the cache, and b) created a huge read queue for the volume. So
whatever anyone else did, they'd generate a read request for data
that was no longer in cache, and suffer the double whammy of having
their request go onto the end of a long queue. Result - a system with
99 to 100% WIO, virtually nothing running, and the phone ringing in
the IT department !
One report I re-wrote in Informix dropped from taking 46 hours over a
weekend to 90 *seconds* and could be run anytime without generating
complaints :-)
--
Simon Hobson
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.