xfs
[Top] [All Lists]

Re: XFS Raid5 in Raid0 poor performance

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: XFS Raid5 in Raid0 poor performance
From: Patrick Cole <z@xxxxxxxxxx>
Date: Fri, 6 Jun 2003 16:06:29 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20030606054045.GC1239@frodo>
References: <20030606045826.GA3070@jaded.neocom> <20030606054045.GC1239@frodo>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4i
Fri, Jun 06, 2003 at 03:40:45PM +1000, Nathan Scott wrote:

> > Some input/ideas/fixes would be appreciated.
> 
> Oh - I wonder if the layering of RAID like this is causing the
> mkfs code to get confused.  (is Martin lurking on the list?)
> 
> I'd suggest trying a mkfs on one of the RAID5 devices, then pass
> those sunit and swidth values into mkfs rather than using the
> ones which it figures out on the fly from your RAID0 device, and
> see if that helps at all.

That wouldn't be advisable as the inner chunk size is only 32KB.  
To get maximal performance from the raid it would need to write/read
2 x 256KB (512KB) to the outer raid for each I/O op. It would be nice 
if the number of data disks in each raid5 was a power of two, but it 
works out a write of 192KB would cover all 6 disks.  256KB or 128KB
is the closest approximation.   
 
> > Btw, the filesystem was created using xfsprogs 2.0.6.  After talking with 
> > sandeen
> > he suggested that the newer utils had some changes relating to setting to 
> > the sunit 
> > and stripe perameters of the filesystem. Is this the case?
> 
> There were changes recently in the MD stripe detection code, just
> to change it so that it wouldn't quit out of mkfs in certain cases
> and instead warn and carry on - so that wouldn't affect you here.
> It's a good idea to get the latest tools though - you might find 
> version 2 logs to be of some help here too, and there was a recent
> mkfs fix for those recently.

Check out:

meta-data=/                      isize=256    agcount=336, agsize=1048544 blks
         =                       sectsz=512  
data     =                       bsize=4096   blocks=351630368, imaxpct=25
         =                       sunit=32     swidth=64 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=32768, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=262144 blocks=0, rtextents=0

What exactly is sunit?  Is it meant to be the stripe chunk size for the given
device?  If it is, then it should be 256, not 32.  That could be the reason
for the shoddy performance?

Cheers

Patrick

-- 
Patrick Cole <Patrick.Cole@xxxxxxxxxx>
Programmer, the John Curtin School of Medical Research, ANU 
Office 02 6125 6794  Mobile 0438 763337
PGP 1024R/60D74C7D C8E0BC7969BE7899AA0FEB16F84BFE5A   


<Prev in Thread] Current Thread [Next in Thread>