From: Mike Snitzer <snitzer@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
dm-devel@redhat.com, linux-kernel@vger.kernel.org,
Heinz Mauelshagen <heinzm@redhat.com>,
Joe Thornber <ejt@redhat.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Paul Taysom <taysom@chromium.org>,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: dm: dm-cache fails to write the cache device in writethrough mode
Date: Fri, 22 Mar 2013 18:34:28 -0400 [thread overview]
Message-ID: <20130322223425.GA5638@redhat.com> (raw)
In-Reply-To: <20130322201151.GB5357@blackbox.djwong.org>
On Fri, Mar 22 2013 at 4:11pm -0400,
Darrick J. Wong <darrick.wong@oracle.com> wrote:
> The new writethrough strategy for dm-cache issues a bio to the origin device,
> remaps the bio to the cache device, and issues the bio to the cache device.
> However, the block layer modifies bi_sector and bi_size, so we need to preserve
> these or else nothing gets written to the cache (bi_size == 0). This fixes the
> problem where someone writes a block through the cache, but a subsequent reread
> (from the cache) returns old contents.
Your writethrough blkid test results are certainly strange. But I'm not
aware of where the block layer would modify bi_size and bi_sector;
please elaborate.
I cannot reproduce your original report. I developed
'test_writethrough_ext4_uuids_match', apologies for the ruby code:
def test_writethrough_ext4_uuids_match
size = meg(10)
# wipe the origin to ensure we don't accidentally have the same
# data on it.
with_standard_linear(:data_size => size) do |origin|
wipe_device(origin)
end
uuid = "deadbeef-cafe-dead-beef-cafedeadbeef"
# format the cache device with a specific uuid
with_standard_cache(:format => true,
:io_mode => :writethrough,
:data_size => size) do |cache|
fs = FS::file_system(:ext4, cache)
fs.format(:uuid => uuid)
FS::assert_fs_uuid(uuid, cache)
end
# origin should have the same uuid as the cache
with_standard_linear(:data_size => size) do |origin|
FS::assert_fs_uuid(uuid, origin)
end
end
This test was committed to the 'devel' branch of my thinp-test-suite
tree: git://github.com/snitm/thinp-test-suite.git
Also the existing 'test_writethrough' test works fine.
So for now:
Nacked-by: Mike Snitzer <snitzer@redhat.com>
next prev parent reply other threads:[~2013-03-22 22:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-22 20:11 [PATCH] dm: dm-cache fails to write the cache device in writethrough mode Darrick J. Wong
2013-03-22 20:21 ` Ben Hutchings
2013-03-22 20:50 ` Darrick J. Wong
2013-03-22 21:35 ` Mike Snitzer
2013-03-22 22:34 ` Mike Snitzer [this message]
2013-03-22 23:16 ` [dm-devel] " Darrick J. Wong
2013-03-23 3:27 ` Mike Snitzer
2013-03-23 3:48 ` [dm-devel] " Alasdair G Kergon
2013-03-23 5:15 ` Darrick J. Wong
2013-03-23 21:08 ` Mike Snitzer
2013-03-23 22:56 ` Mike Snitzer
2013-03-25 23:59 ` [PATCH v2] dm cache: fix writes to " Mike Snitzer
2013-03-23 21:13 ` [dm-devel] dm: dm-cache fails to write the " Alasdair G Kergon
2013-03-23 3:00 ` [dm-devel] [PATCH] " Alasdair G Kergon
2013-03-25 10:28 ` Joe Thornber
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=20130322223425.GA5638@redhat.com \
--to=snitzer@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=dm-devel@redhat.com \
--cc=ejt@redhat.com \
--cc=heinzm@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=rdunlap@infradead.org \
--cc=taysom@chromium.org \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.