[Sussex] Hardware Raid Question

[Dave Chapman]

On Sunday 28 August 2005 00:14, Steve Dobson wrote:
> 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.
OOpsy
My /home usually has a lot of data for storage rather than manipulation.

Filesystem     1K-blocks      Used          Available Use%  Mounted on
/dev/sda1       17775324     8047700     9727624  46%    /home
/dev/sdb1       17919896     15600092   2319804  88%    /home/dave

Maybe I should just have a clear out.
>
> 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