Determining whether stripe unit and stripe size were detected correctly

[Simpson, John R]

> -----Original Message-----
> From: xfs-bounces at oss.sgi.com [mailto:xfs-bounces at oss.sgi.com] On Behalf
> Of Eric Sandeen
> Sent: Thursday, April 07, 2016 4:22 PM
> To: xfs at oss.sgi.com
> Subject: Re: Determining whether stripe unit and stripe size were
> detected correctly
> 
> 
> 
> On 4/7/16 3:16 PM, Simpson, John R wrote:
> > Greetings,
> >
> >
> >
> >                 I'm in the process of tracking down lower than
> expected performance and occasional blocked tasks on some internal file
> servers with XFS datastores.  Several sources have pointed out the
> importance of using the correct stripe unit and stripe size when
> formatting and mounting XFS filesystems, and that XFS can detect these
> values for some, but not all, hardware RAID controllers.  The servers in
> question are PowerEdge R510b servers with PERC H700 controllers.
> Datastores are RAID5 with a 128K stripe.
> >                 Is there any way to determine if the stripe unit and
> stripe size were detected correctly?  These values were not specified
> when the filesystems were formatted or mounted.  If they were not
> detected, is there any way to determine them programmatically?
> >                 If this is not the correct forum for this question
> please point me in the right direction.
> >
> >
> >
> > Best regards,
> 
> > # xfs_info /DS01
> >
> > meta-data=/dev/sdb1              isize=256    agcount=5,
> agsize=268435455 blks
> >          =                       sectsz=512   attr=2, projid32bit=0
> > data     =                       bsize=4096   blocks=1212415488,
> imaxpct=5
> >          =                       sunit=0      swidth=0 blks
> 
> sunit == swidth == 0, so no geometry is present on this filesystem.
> 
> > naming   =version 2              bsize=4096   ascii-ci=0
> > log      =internal               bsize=4096   blocks=521728, version=2
> >          =                       sectsz=512   sunit=0 blks, lazy-
> count=1
> > realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> mkfs.xfs uses values exported by the block device, and can be seen by
> using blockdev to query them, i.e.
> 
> blockdev --getiomin --getioopt /dev/sdb1
> 
> If it returns 0, no geometry is exported by the device, and you'd need
> to use your own knowledge of the device to set appropriate values (and
> to properly partition on aligned boundaries as well)
> 
> -Eric
> 

Thank you, I was hoping sunit == swidth == 0 meant 'auto-detected' but suspected that wasn't the case.  It looks like blockdev is reporting 0 for getioopt so we'll have to calculate and supply sunit and swidth.  I believe the partition is properly aligned, I used the following.  Any suggested improvements are appreciated.

parted --align optimal --script $device mklabel gpt mkpart -- primary 1 -1

Blockdev reports:

#  blockdev --getiomin --getioopt /dev/sdb1
512
0


Is there a way, other than testing, to determine the potential performance improvement gained by providing the geometry?

John

> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs