public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org, g.danti@assyoma.it
Subject: Re: XFS and sector size on thin volumes
Date: Tue, 12 Sep 2017 00:14:19 +0200	[thread overview]
Message-ID: <838841738c3d8ca84328075615f95475@assyoma.it> (raw)
In-Reply-To: <20170909235323.GL17782@dastard>

> If a block device is presented with 512 sectors on 4k-only sector
> drives, then that's a bug. If it's doing so with 512e drives,
> then that's still a bug because it should be presenting as a
> 512 byte logical, 4096 byte physical sector size device and in that
> case mkfs.xfs will choose 4k sectors by default.
> 
> IOWs, if the underlying device is correctly presented to mkfs.xfs
> then it will choose the correct sector size by default.  dm-thinp
> does the right thing with sector sizes, but I have no idea about
> ZoL.

Hi Dave,
it seems ZVOLs behave... interestingly...

# 4K volume
[root@blackhole ~]# zfs create tank/vol1 -V 300M -b 4k
[root@blackhole ~]# blockdev --getss --getpbsz --getiomin --getioopt 
/dev/zvol/tank/vol1
512
4096
4096
4096

# 8K volume
[root@blackhole ~]# zfs create tank/vol1 -V 300M -b 8k
[root@blackhole ~]# blockdev --getss --getpbsz --getiomin --getioopt 
/dev/zvol/tank/vol1
512
8192
8192
8192

# 128K volume
[root@blackhole ~]# zfs create tank/vol1 -V 300M -b 128k
[root@blackhole ~]# blockdev --getss --getpbsz --getiomin --getioopt 
/dev/zvol/tank/vol1
512
131072
131072
131072

So, it seems that volume's block size does not only change the 
iomin/ioopt values, but pbsz also. On the other hand, ss is stuck at 
512B, even if I am using a 512e (4K physical sector size) underlying 
disk:

[root@blackhole ~]# blockdev --getss --getpbsz --getiomin --getioopt 
/dev/sdc
512
4096
4096
0

Creating an XFS filesystem on such a ZVOL will issue the following 
message:

"specified blocksize 4096 is less than device physical sector size 8192
switching to logical sector size 512"

In this case, should I specify block size (-b size=4k) at mkfs.xfs time, 
or not?
Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

  reply	other threads:[~2017-09-11 22:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-09 22:11 XFS and sector size on thin volumes Gionatan Danti
2017-09-09 23:12 ` Dave Chinner
2017-09-09 23:26   ` Gionatan Danti
2017-09-09 23:53     ` Dave Chinner
2017-09-11 22:14       ` Gionatan Danti [this message]
2017-09-11 22:28         ` Eric Sandeen
2017-09-12  5:24           ` Gionatan Danti
2017-09-16 16:43             ` Gionatan Danti
2017-09-16 18:33               ` Eric Sandeen
2017-09-16 19:59                 ` Gionatan Danti
2017-09-16 22:01                   ` Eric Sandeen

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=838841738c3d8ca84328075615f95475@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    /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