7

I created an XFS file system using default parameters at the time of creation of a system. Now looking at the output of xfs_info, it show 0 for the values of sunit and swidth. I can't seem to find an explanation of what 0 means in this context. (The discussions of sunit and swidth that I have found are focused on setting the correct values for these parameters, not setting them to 0.)

# xfs_info .
meta-data=/dev/mapper/centos-root isize=256    agcount=8, agsize=268435455 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=1927677952, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=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

This must be an ignorant question, for which I apologize because I am an XFS newbie, but what is the meaning of 0 values for sunit and swidth? How can I find out what XFS is really using for those parameter values, and how those values relate to the values that would be appropriate for my RAID array? (This is an XFS system on top of LVM on top of hardware RAID.)

mhucka
  • 679
  • 4
  • 10
  • 22
  • 1
    Means it won't optimize for the underlying RAID stripes if there are any. Most often seen for mirrored drives / RAID1 as they don't have stripes. – Brian Nov 21 '15 at 19:14

3 Answers3

1

This is an old question, but I think a more comprehensive answer can be useful.

In short: when using software RAID, let XFS autodetect the underlying array geometry. If using hardware RAID on recent kernel, XFS should be capable of autodetecting the correct parameters; if no, you can use su/sw/sunit/swidth to specify them.

Knowing the underlying geometry helps the XFS allocator to avoid crossing two disks when possible, conserving IOPS for other works (ie: less data disk are engaged).

In the specific example above, where mkfs.xfs report both sunit=0 and swidth=0, it means XFS did not detect any specific RAID geometry on the block device where the filesystem was created.

Long answer: Let's start from su and sw. From the (somewhat outdated) XFS faq:

su = <RAID controllers stripe size in BYTES (or KiBytes when used with k)>
sw = <# of data disks (don't count parity disks)>

Note that in this context, "stripe size" refer to the single stripe unit size, also called chunk size by Linux MD RAID. Again from the faq:

A RAID stripe size of 256KB with a RAID-10 over 16 disks should use

su = 256k sw = 8 (RAID-10 of 16 disks has 8 data disks)

sunit and swidth are another method to express the same RAID geometry, this times in 512B sectors. From mkfs.xfs man page:

sunit

This is used to specify the stripe unit for a RAID device or a logical volume. The value has to be specified in 512-byte block units

swidth

This is used to specify the stripe width for a RAID device or a striped logical volume. The value has to be specified in 512-byte block units.

In short:

su * sw = entire data stripe size
swidth / sunit = number of data disk

As you can see, they are two different methods to inform XFS about the underlying RAID geometry. However, the faq tell us about a catch in how mkfs.xfs reports sunit and swidth:

Note that xfs_info and mkfs.xfs interpret sunit and swidth as being specified in units of 512B sectors; that's unfortunately not the unit they're reported in, however. xfs_info and mkfs.xfs report them in multiples of your basic block size (bsize) and not in 512B sectors.

Assume for example: swidth 1024 (specified at mkfs.xfs command line; so 1024 of 512B sectors) and block size of 4096 (bsize reported by mkfs.xfs at output). You should see swidth 128 (reported by mkfs.xfs at output). 128 * 4096 == 1024 * 512.

Basically, when making a filesystem you specify sunit and swidth in 512B sectors, while the very same mkfs.xfs report them in 4K block size. This difference is a common source of confusion.

shodanshok
  • 47,711
  • 7
  • 111
  • 180
0

Zero means zero optimization of extent allocation wrt the underlying RAID structure, that's right.

So if you are concerned with performance and you simply can recreate the FS, analyze the # of drives and their chunk size in your raid set/controller and set sunit and swidth accordingly in mkfs.xfs.

And if (and only if) you need to create partition(s) on the RAID LUN, make sure the first starts at a 1 MByte boundary (2048s if sector = 512 bytes), as this is what most RAID chunk sizes are divisible by.

Christian
  • 295
  • 1
  • 7
0

if you're not using RAID, sunit and swidth options are obsolete, its for RAID optimization

for more info about sunit and swidth refer to XFS FAQ

Vasil Jamalashvili
  • 31
  • 5
  • 1
    It *is* a RAID system. – mhucka Nov 21 '15 at 18:41
  • 1
    Also, the FAQ that you quoted is part of the problem I'm asking about: it tells me how to set explicit values, but does not say why the defaults are 0, or what it means if they are 0. – mhucka Nov 21 '15 at 18:47