Subject: Re: Why did my strip array slow down?
To: Byron Servies <bservies@pacang.com>
From: Byron Servies <bservies@pacang.com>
List: netbsd-users
Date: 11/08/2002 19:24:17
On November 08, 2002 at 09:08, Byron Servies wrote:
> 
> The directory I am writing to has a large number of files.
> Writing to it's parent also causes a long wait before transfer
> begins, but writing to an empty subdirectory starts right
> up.  Perhaps this is the effect of the 63 secPerSU you mention
> below?
> 
> I will re-configure the raid array and see if that helps.
> 
> > > -- raid0.conf
> > > 
> > > START array
> > > # numRow numCol numSpare
> > > 1 2 0
> > > 
> > > START disks
> > > /dev/wd1h
> > > /dev/wd2h
> > > 
> > > START layout
> > > # sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level_0
> > > 63 1 1 0
> > 
> > Is this really 63?  63 might help scatter directory bits better, but 
> > I'm not sure it would be better than 64 for general performance.
> > (For a 32K write, for example, you'll be putting (at most) 31.5K on one
> > disk, and then have to do a separate IO for the remaining 0.5K to the other 
> > disk...  With an 8K write, even that could end up being split over both disks,
> > which could be slightly slower.   I'm not sure that this is the cause
> > of the performance problems, but it probably isn't helping anything :( )
> 
> Yes, it's 63.  I have forgotten why I chose this value; it was
> after an afternoon of reading raidframe docs, though.

Reconfiguring the array to "128 1 1 0" seems to have done
the trick and gotten me past this fence: the new array
accepted 60gb of ftp'd data without slowing and was faster
than the previous array.  I will re-read the raidframe
documentation before reconfiguring the array again.

Thanks for the help,

Byron