public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: makefs alignment issue
Date: Fri, 24 Oct 2014 17:08:04 -0500	[thread overview]
Message-ID: <544ACDC4.1070501@hardwarefreak.com> (raw)
In-Reply-To: <544AB338.2050905@sandeen.net>


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

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

  reply	other threads:[~2014-10-24 22:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 20:11 makefs alignment issue Stan Hoeppner
2014-10-24 20:14 ` Eric Sandeen
2014-10-24 22:08   ` Stan Hoeppner [this message]
2014-10-24 22:19     ` Eric Sandeen
2014-10-24 22:27       ` Eric Sandeen
2014-10-25  3:08         ` Stan Hoeppner
2014-10-25 15:51           ` Eric Sandeen
2014-10-25 17:35             ` Stan Hoeppner
2014-10-26 23:43               ` Dave Chinner
2014-10-27 23:04                 ` Stan Hoeppner
2014-10-28  0:32                   ` Dave Chinner
2014-10-28 16:55                     ` Stan Hoeppner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=544ACDC4.1070501@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox