On Fri, 2004-03-05 at 03:59, Ramesh K wrote:
> Hello,
> I finally managed to get realtime subvolumes working in my system. I
> built a new kernel using the sources at SGI (Kernel 2.4.25). I have also been
> testing the realtime subvolumes with my application.
> The application writes data to a XFS realtime subvolume at 80
> MBytes/sec. I'm using 3ware Raid Controller 7810, configured as RAID 0 with
> 64K
> stripes.
> The man page of mk.xfs says, "the real-time extent size should be
> carefully chosen to match the parameters of the physical media used" - can
> someone say more about this? What more do I need to know about the ophysical
> media?
> Here's the output generated by xfs_info:
>
> /******************************************************/
> kram@dop93:~> xfs_info /data
> meta-data=/data isize=256 agcount=25, agsize=1048576 blks
> = sectsz=512
> data = bsize=4096 blocks=25601577, imaxpct=25
> = sunit=0 swidth=0 blks, unwritten=0
> naming =version 2 bsize=4096
> log =internal bsize=4096 blocks=12500, version=1
> = sectsz=512 sunit=0 blks
> realtime =external extsz=65536 blocks=208836967,
> rtextents=13052310
>
> /****************************************************/
>
> The RAID controller document says that smaller stripe width is more
> suited for sequential access, and that is what I do. I use preallocated files
> in realtime subvolume. What I see is the disk-pack exhibits some sort of
> sponginess with time. Is it entirely due to the RAID Controller + harddisk
> combination, or is it something from XFS realtime subvolumes? I can include
> some
> statistics of the latencies if you need.
> Thank you.
>
> Regards
> Ramesh
>
>
I think with RAID-0 you will want to recreate the filesystem using sunit
and swidth, on both the log on the data. There are better minds than
mine for this on here, but I think that "-d swidth=(n disks),sunit=64k"
Someone may comment on log size - I don't know if it should be largers,
I think for the log you want "-l sunit=128" [isn't the sunit here in 512
blocks?] .
thanks,
joshua
|