xfs
[Top] [All Lists]

Re: makefs alignment issue

To: Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: makefs alignment issue
From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Fri, 24 Oct 2014 17:08:04 -0500
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <544AB338.2050905@xxxxxxxxxxx>
References: <544AB289.8010005@xxxxxxxxxxxxxxxxx> <544AB338.2050905@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0
On 10/24/2014 03:14 PM, Eric Sandeen wrote:
> On 10/24/14 3:11 PM, Stan Hoeppner wrote:
>> Just remade a couple of filesystems and received an alignment msg I
>> don't recall receiving previously:
>>
>> # mkfs.xfs -f -d su=64k,sw=12 /dev/s2d_a1l003
>> mkfs.xfs: Specified data stripe width 1536 is not the same as the volume
>> stripe width 2048
> 
> so specified geometry that differs from the underlying device...
> 
>> meta-data=/dev/s2d_a1l003        isize=256    agcount=44,
>> agsize=268435440 blks
>>          =                       sectsz=512   attr=2, projid32bit=0
>> data     =                       bsize=4096   blocks=11709285376, imaxpct=5
>>          =                       sunit=16     swidth=192 blks
>> naming   =version 2              bsize=4096   ascii-ci=0
>> log      =internal log           bsize=4096   blocks=521728, version=2
>>          =                       sectsz=512   sunit=16 blks, lazy-count=1
>> realtime =none                   extsz=4096   blocks=0, rtextents=0
>>
>>
>> /dev/s2d_a1l003 is an alias to dm-0 which is a dm-multipath device to a
>> LUN on hardware RAID.  The hardware geometry is 64kx 12, 768k.  AFAIK no
>> geometry information has been specified for these device mapper devices
>> (someone else's responsibility).  Though I assume dm geometry data is
>> the reason for mkfs.xfs throwing this alert.  I don't find anything in
>> /sys/devices/virtual/block/dm-0/ indicating geometry.
>>
>> Any ideas how to verify what's going on here and fix it?
> 
> # blockdev --getiomin --getioopt /dev/s2d_a1l003
> 
> The first number, minimum io size, is what is used for sunit
> The 2nd number, optimal io size, is what is used for swidth
> 
> Where dm got the geometry, I'm not sure - you'd have to look into
> how you set up the dm device, and what its defaults are I think.

Looks like they're being passed up the stack:
# blockdev --getiomin --getioopt /dev/dm-0
512
1048576

# multipath -ll
3600c0ff0003630917954075401000000 dm-0 Tek,DH6554
size=44T features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| `- 9:0:0:3 sdj 8:144 active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
  `- 1:0:0:3 sdf 8:80  active ready running

/sys/block/sdj/queue# cat minimum_io_size
512
/sys/block/sdj/queue# cat optimal_io_size
1048576

root@Anguish-ssu-1:/sys/block/sdf/queue# cat minimum_io_size
512
root@Anguish-ssu-1:/sys/block/sdf/queue# cat optimal_io_size
1048576

So it's the presence of a value in optimal_io_size that causes the
problem here.  My single disk workstation has min but not optimal, as I
assume most do.  And I don't get this msg when formatting it.

It's interesting that mkfs.xfs would use these values given they are
static firmware values in most controllers.  Thus they don't change when
one uses different geometry for different arrays/LUNs...

So it seems I can safely ignore this mkfs msg.

Thanks,
Stan

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