[Top] [All Lists]

Re: [PATCH 1/2] xfsprogs: ignore stripe geom if sunit or swidth == physi

To: Eric Sandeen <sandeen@xxxxxxxxxxx>, Brian Foster <bfoster@xxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxx>
Subject: Re: [PATCH 1/2] xfsprogs: ignore stripe geom if sunit or swidth == physical sector size
From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Wed, 29 Oct 2014 16:38:22 -0500
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <54513635.7050703@xxxxxxxxxxx>
References: <544FD3E1.1060000@xxxxxxxxxx> <20141029183721.GA4226@xxxxxxxxxxxxxx> <54513635.7050703@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0
On 10/29/2014 01:47 PM, Eric Sandeen wrote:
> On 10/29/14 1:37 PM, Brian Foster wrote:
>> On Tue, Oct 28, 2014 at 12:35:29PM -0500, Eric Sandeen wrote:
>>> Today, this geometry:
>>> # modprobe scsi_debug  opt_blks=2048 dev_size_mb=2048
>>> # blockdev --getpbsz --getss --getiomin --getioopt  /dev/sdd
>>> 512
>>> 512
>>> 512
>>> 1048576
>>> will result in a warning at mkfs time, like this:
>>> # mkfs.xfs -f -d su=64k,sw=12 -l su=64k /dev/sdd
>>> mkfs.xfs: Specified data stripe width 1536 is not the same as the volume 
>>> stripe width 2048
>>> because our geometry discovery thinks it looks like a
>>> valid striping setup which the commandline is overriding. 
>>> However, a stripe unit of 512 really isn't indicative of
>>> a proper stripe geometry.
>> So the assumption is that the storage reports a non-physical block size
>> for minimum and optimal I/O sizes for geometry detection. There was a
>> real world scenario of this, right? Any idea of the configuration
>> details (e.g., raid layout) that resulted in an increased optimal I/O
>> size but not minimum I/O size?
> Stan?  :)

Yeah, it was pretty much what you pasted sans the log su, and it was a
device-mapper device:

# mkfs.xfs -d su=64k,sw=12 /dev/dm-0


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