xfs
[Top] [All Lists]

Re: XFS, RAID-5, 3ware

To: Gaspar Bakos <gbakos@xxxxxxxxxxxxxxx>
Subject: Re: XFS, RAID-5, 3ware
From: Chris Wedgwood <cw@xxxxxxxx>
Date: Thu, 19 May 2005 18:01:28 -0700
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <Pine.SOL.4.58.0505191735250.26773@titan.cfa.harvard.edu>
References: <Pine.SOL.4.58.0505191735250.26773@titan.cfa.harvard.edu>
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Thu, May 19, 2005 at 06:06:25PM -0400, Gaspar Bakos wrote:

> I have a 3ware hardware RAID-5 array of 8 300Gb disks. The stripe
> size is 256k. By the way, 3ware recommends small stripe size for
> sequental access (video). and large strip for random access (DB,
> random files, etc.) I wonder if there is any experience related to
> this statement.

It depends on what your average write size is and also the alignment
of writes too.

> mkfs.xfs -f -b size=4k -d su=256k,sw=7 -i size=1k -l size=128m,su=256k \
>       /dev/sdc1 -L "big"

-isize=512 would be fine

-lversion=2 maybe

>    size: how to determine the optimal size?

page-size

>    Currently I am using the default, which is 4K.

yup

> 2. -d
>    su: the strip size of the RAID-5
>    sw: n-1, where n is the number of disks
>    agcount: my understanding is that this is quite well optimized in an
>      automated way, thus I use the default.

the defaults here don't work optimally for hardware raid as there is
no way to reasonably determine the underlying geometry of the device
like their is for softraid.

you are manually specifying these so i'm not sure it matters

> 3. -i
>    size: how to determine the optimal size?

512-bytes is the minimum you can get away with to spread inodes out
evenly over a volume larger than 2TB

>    many small files; use large inode size?

not neceessarily

> few large files: use small inode?

not neceessarily

>    What I read somewhere:

>     can't exceed half the allocation block size, though.) One impact of
>     the inode size option relates to small file access times; because
>     XFS tries to store small files within the inode whenever
>     possible,

this is only true for special files (like directories), normal files
will not be stored in the inode

>     specifying a large inode enables storing larger files within the
>     inode. Doing so will speed access to these files. Therefore, if
>     a partition will store many small files (under 2KB), you may
>     want to increase the inode size. Depending on the exact mix of
>     file sizes, the result may save or waste disk space.

inodes are allocated on demand (and the mount option "noikeep" means
they will be pruned when not needed) so I'm not sure what this is all
about

>     If few files will be smaller than 2KB, there's little point to
>     increasing the inode size.

i'm not sure what their logic is there

> 4. -l
>    size:
>      The default value for my setup turns out to be
>            log      =internal log           bsize=4096   blocks=32768, 
> version=1
>                     =                       sectsz=512   sunit=0 blks
>      This corresponds to size=128m

>     su: should be set to the stripe size of the RAID-5 array for
>     optimal performance?

yes, i think if you specify it for the data and use v2 logs it will
get this right though?

> Let me know if there are any comments, and I you see that we are doing
> something crazy:
> 
> root$ mkfs.xfs -f -b size=4k -d su=256k,sw=7 -i size=1k -l size=128m,su=256k \
>       /dev/sdc1 -L "big"

> log stripe unit specified, using v2 logs

ah cool, it does this automagically



i think i would try a few things out and see how it goes.  i don't
know how much cache in the raid-controller and what your write
patterns will be but a 256k strip-unit seems really large to me and i
would experiement with different values with your workload and see how
it works out


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