linux-kernel - Re: dm: dm-cache fails to write the cache device in writethrough mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Mar 2013 23:27:16 -0400
From:	Mike Snitzer <snitzer@...hat.com>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	device-mapper development <dm-devel@...hat.com>,
	Heinz Mauelshagen <heinzm@...hat.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Joe Thornber <ejt@...hat.com>,
	Mikulas Patocka <mpatocka@...hat.com>,
	Paul Taysom <taysom@...omium.org>
Subject: Re: dm: dm-cache fails to write the cache device in writethrough mode

On Fri, Mar 22 2013 at  7:16pm -0400,
Darrick J. Wong <darrick.wong@...cle.com> wrote:

> On Fri, Mar 22, 2013 at 06:34:28PM -0400, Mike Snitzer wrote:
> > On Fri, Mar 22 2013 at  4:11pm -0400,
> > Darrick J. Wong <darrick.wong@...cle.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:
> 
> Hmm... I'm building my kernels off 0a7e453103b9718d357688b83bb968ee108cc874 in
> Linus' tree (post 3.9-rc3).  This is the full output of dmsetup table:
> 
> moocache-blocks: 0 1039360 linear 8:16 9088
> moocache-metadata: 0 8704 linear 8:16 384
> moocache: 0 67108864 cache 253:0 253:1 8:0 512 1 writethrough default 4 random_threshold 4 sequential_threshold 32768
> 
> 253:0 -> moocache-metadata and 253:1 -> moocache-blocks.
> 
> I'm curious what your setup is...

Here are the tables:
test-dev-238267: 0 8192 linear /dev/stec/metadata 0
test-dev-255913: 0 2097152 linear /dev/stec/metadata 8192
test-dev-655144: 0 20480 linear /dev/spindle/data 0
0 20480 cache /dev/mapper/test-dev-238267 /dev/mapper/test-dev-255913 /dev/mapper/test-dev-655144 512 1 writethrough default 0

And I tweaked 'test_writethrough_ext4_uuids_match' to make sure to use the
same thresholds you're using, full status output:
0 20480 cache 15/1024 0 19 0 0 0 0 0 0 1 writethrough 2 migration_threshold 32768 4 random_threshold 4 sequential_threshold 512

So the big difference is the thinp-test-suite uses intermediate linear
DM layers above the slower sd device (spindle/data) -- whereas in your
setup the origin device is direct to sd (8:0).

I'll re-run with the origin directly on sd in the morning and will
report back.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/