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.
next prev 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).