linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Dave Chinner <david@fromorbit.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-xfs@vger.kernel.org
Subject: Re: dm-writecache issue
Date: Tue, 18 Sep 2018 09:20:53 -0500	[thread overview]
Message-ID: <20180918142053.GA26193@redhat.com> (raw)
In-Reply-To: <817349b8-b54e-a16a-276f-7a977f29b449@sandeen.net>

On Tue, Sep 18, 2018 at 07:48:04AM -0500, Eric Sandeen wrote:
> Not only that, but it must have told us that it had a /physical/ 512 sector.
> If it had even said physical/logical 4096/512, we would have chosen 4096.

Right, just after asking I discovered that the advertised
physical_block_size changes after attaching dm-writecache:

Before:

# dmsetup ls
foo-main        (253:3)
foo-fast        (253:4)

# cat /sys/block/dm-3/queue/physical_block_size 
512
# cat /sys/block/dm-4/queue/physical_block_size 
4096

After:

# dmsetup ls
foo-main_wcorig (253:4)
foo-main        (253:5)
foo-fast        (253:3)

# cat /sys/block/dm-3/queue/physical_block_size 
4096
# cat /sys/block/dm-5/queue/physical_block_size 
4096


> What does please check blockdev --getpbsz --getss /dev/$FOO say at mkfs time?

Before:

# blockdev --getpbsz --getss /dev/foo/main
512
512

After:

# blockdev --getpbsz --getss /dev/foo/main
4096
4096


> > Yes, it does, but mkfs should also fail when it tries to write 512
> > byte sectors to a 4k device, too.

By default it uses the 4k sectors in that case:

# mkfs.xfs -f /dev/foo/main
meta-data=/dev/foo/main          isize=512    agcount=4, agsize=13056 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=52224, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=1605, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


But you are correct if I request 512 on a 4k device:

# mkfs.xfs -f -s size=512 /dev/foo/main
illegal sector size 512; hw sector is 4096

> > I'm betting that the underlying device advertised a logical/physical
> > sector size of 512 bytes to mkfs, and then adding pmem as the cache
> > device changed the logical volume from a 512 byte sector device to a
> > hard 4k sector device.

Yes

I've been dealing with this by just using -s size=4096.

  parent reply	other threads:[~2018-09-18 19:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180911221147.GA23308@redhat.com>
2018-09-18 11:46 ` dm-writecache issue Mikulas Patocka
2018-09-18 12:32   ` Dave Chinner
2018-09-18 12:48     ` Eric Sandeen
2018-09-18 14:09       ` Mikulas Patocka
2018-09-18 14:16         ` Eric Sandeen
2018-09-18 14:19           ` Eric Sandeen
2018-09-18 14:29             ` Mikulas Patocka
2018-09-18 14:36               ` Eric Sandeen
2018-09-18 14:42                 ` Mikulas Patocka
2018-09-18 15:04                   ` Eric Sandeen
2018-09-18 15:27                     ` Eric Sandeen
2018-09-18 15:29                       ` Christoph Hellwig
2018-09-18 17:15                     ` Mikulas Patocka
2018-09-18 14:20       ` David Teigland [this message]
2018-09-18 14:23         ` Eric Sandeen
2018-09-18 14:22     ` Mikulas Patocka
2018-09-18 15:33       ` Christoph Hellwig
2018-09-18 17:39         ` Mikulas Patocka
2018-09-18 22:52           ` Dave Chinner

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=20180918142053.GA26193@redhat.com \
    --to=teigland@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=sandeen@sandeen.net \
    /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;
as well as URLs for NNTP newsgroup(s).