Can you provide the output of:

# blockdev --getss --getpbsz --getiomin --getioopt --getbsz /dev/5tb.Toshiba-Lot/raid5

please?

thanks,
-Eric

blockdev --getss --getpbsz --getiomin --getioopt --getbsz /dev/5tb.Toshiba-Lot/raid5
512
4096
4096
36864
4096

So:

Sector size: 512
Physical block size: 4096
Minimum IO size: 4096
Optimal IO size: 36k

mkfs uses minimum and optimal sizes for stripe unit and stripe width:

        val = blkid_topology_get_minimum_io_size(tp);
        *sunit = val;
        val = blkid_topology_get_optimal_io_size(tp);
        *swidth = val;

but a stripe unit which matches the physical block size is not a stripe unit at all:

        /*
         * If the reported values are the same as the physical sector size
         * do not bother to report anything.  It will only cause warnings
         * if people specify larger stripe units or widths manually.
         */
        if (*sunit == *psectorsize || *swidth == *psectorsize) {
                *sunit = 0;
                *swidth = 0;
        }

That's why it's coming up zero.

And sunit == psectorsize because that's what you specified on the lvcreate commandline, with -I 4:

       -I, --stripesize StripeSize
              Gives the number of kilobytes for the granularity of the stripes.

so the problem here is your lvcreate commandline, I think.  Did you really want a 4k stripe unit?

-Eric

So, I'm inclined to close this NOTABUG.  mkfs.xfs intentionally ignores a stripe unit of the size you specified... thoughts?

yes, it seems ok when, eg. -I 8

mkfs.xfs /dev/5tb.Toshiba-Lot/raid5 
meta-data=/dev/5tb.Toshiba-Lot/raid5 isize=256    agcount=41, agsize=268435454 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=10988467200, imaxpct=5
         =                       sunit=2      swidth=18 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

but what's wrong with stripe size of 4Kb? I though arrays spanning larger number of drives are better off with smaller stripe sizes so I went with 4Kb.

but also(or separate thing happens to my ext4 on the same VG, this time it's a simple stripe:

lvcreate -i 4 -I 4 -n raid0

and dumpe2fs -h

Inode blocks per group:   128
RAID stripe width:        4
Flex block group size:    16
Filesystem created:       Thu Apr 16 23:56:14 2015

so it seems that 4K is the rule across the OS, what's the reasoning behind it?

The reason mkfs.xfs rejects/ignores stripe unit == physical sector size as a valid stripe geometry is because some non-striped storage reports an "optimal IO size" as the physical sector size:

commit 3dc7147f03cdd4cfe689d78d4ca4b2650c49a263
Author: Eric Sandeen <sandeen>
Date:   Wed Dec 12 17:26:24 2012 -0600

    mkfs.xfs: don't detect geometry values <= psectorsize
    
    blkid_get_topology() ignores devices which report 512
    as their minimum & optimal IO size, but we should ignore
    anything up to the physical sector size; otherwise hard-4k
    sector devices will report a "stripe size" of 4k, and warn
    if anything larger is specified:
    
    # modprobe scsi_debug physblk_exp=3 num_parts=2 dev_size_mb=128
    # mdadm --create /dev/md1 --level=0 --raid-devices=2  -c 4 /dev/sdb1 /dev/sdb2
    # mkfs.xfs -f -d su=16k,sw=2 /dev/md1
    mkfs.xfs: Specified data stripe unit 32 is not the same as the volume stripe unit 
    mkfs.xfs: Specified data stripe width 64 is not the same as the volume stripe widt
    ...

Generally you'll want stripe units larger than a 4k, which is a single filesystem block.  Unless there's a compelling reason to need a 4k stripe unit, I think your best path forward is to just create your raid with a larger stripe unit.

Closing NOTABUG; this is working as designed.