[Sussex] Hardware Raid Question

[Steve Dobson]

Dave

On Sat, Aug 27, 2005 at 06:46:26PM +0100, Dave Chapman wrote:
> On Saturday 27 August 2005 16:59, Steve Dobson wrote:
> > On Sat, Aug 27, 2005 at 04:43:25PM +0100, Dave Chapman wrote:
> > > I have a 64bit ultra 160 raid card and 2 U160 18Gb hard drives and was
> > > wondering what sort of configuration would work best.
> >
> > That depends upon what you want to do.  There is no single answer that
> > is best for everyone.
> >
> > > The card has 2 channels so I was thinking 1 drive on each stripped to
> > > make a 36Gb partion.
> >
> > That would give you a single large partition.  You should get good speed
> > performance as the data is spread over both disks equally, but should *one*
> > disk die then *all* data is lost.
> >
> > Mirroring should give slower write times (the data as to be written to
> > *both* disks), but reads can be quicker than stripping, as a read request
> > can be made of *both* disks but only has to wait for *one* disk to
> > complete.
>
> In this case would 1 disk per channel help performance as opposed to both 
> disks on 1 channel

It is probably best to put the disks on separate channels to spread the
load.  But see below.  But I forgot to say last time that mirroring,
because the same info is written to both disks does not maximum storages,
both disks have identical copies of the data.
 
> > > Would I get the best performance using it for /home or /
> >
> > That depends up the use your system is doing.  If the majority of data
> > accesses is the the / partition then that is where you want your fastest
> > disks.  However, if most of the data is going to /home (because you're
> > editing video for example) then that would be were I place the disks.
>
> /home usually has data for storage rather than manipulation.

Strange.  I normally manipulate data in my home directory rather than
in other places, of course this is for my laptop, which is used as a
desktop system.  On a server things are different.

> So I could have / & /home on the raid partion and a separate disk for stuff 
> like mp3's and pictures that are not accessed often.
> Say /data
> read/write to users

Your talking here about tuning your system, and there are no easy answers.
I've always found tuning to be a black art - half the time the changes I've
made have made things worse not better.

The best tuning I was involved in happened years ago.  It was a highly
customised data application.   The first thing we did was write a
benchmark to work out to write the data.

The data was being store raw to disk - no file system, we had four disks,
two per channel.  We had to problems, making sure that all writes happened
fast enough as incoming data rate was fixed, and balancing the load under
all read conditions (when no writing was happening), at times we were
subsampling the data and at first we were putting all the load on to only
one disk.  Some clever thinking got us out of it.

The point is that our benchmark, even though we knew what our application
needed to do did *not* provide the answer by itself.  It wasn't until we
had the real application running, that we found all the performance problems.

The best advice I have is monitor your system in real life usage and see
how it performs.  Tools like iostat are great for this.  But you need to
understand your system as a whole.  The performance bottleneck could be in
another place.

I can remember attending a talk given by one of the Linux Kernel Hackers
on the use of the buffer cache.  It is the buffer cache that stores your
data in the system when it is read from (or before it is write-n to) disk.
At different times of the say the system was being used for different
things - random access to files during the data, backup at night.  These
two everyday modes of use use the buffer cache very differently and
finding a way of writing the buffer cache to support both efficiently was
the subject of his research.

Steve
-- 
Overflow on /dev/null, please empty the bit bucket.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.lug.org.uk/pipermail/sussex/attachments/20050827/a5dbb2f4/attachment.pgp