On Fri, Mar 22, 2013 at 11:53:26AM -0700, Darrick J. Wong wrote: > On Thu, Mar 21, 2013 at 02:26:26AM +0000, Alasdair G Kergon wrote: > > Please pull from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm tags/dm-3.9-fixes > > > > to get the following device-mapper fixes for 3.9. > > > > Thanks, > > Alasdair > > > > ---------------------------------------------------------------- > > A set of device-mapper fixes for 3.9. > > > > Fix reported data loss with discards and thin snapshots; avoid a > > deadlock observed in dm verity; fix a race in the new dm cache code > > along with some other minor bugs; store the cache policy version on disk > > to make the stored hints format future-proof. > > > > ---------------------------------------------------------------- > > Heinz Mauelshagen (2): > > dm cache: detect cache_create failure > > dm cache: avoid calling policy destructor twice on error > > > > Joe Thornber (5): > > dm thin: fix discard corruption > > dm thin: fix non power of two discard granularity calc > > dm cache: avoid 64 bit division on 32 bit > > dm cache: metadata clear dirty bits on clean shutdown > > dm cache: fix race in writethrough implementation > > I think I've found a bug in this new WT implementation. /dev/sdb is an SSD, > /dev/sda is a spinny disk, and both have been zeroed prior to running the > following: > > # pvcreate /dev/sdb > # vgcreate -s 256K moocache /dev/sdb > # lvcreate -n metadata moocache -l 17 > # lvcreate -n blocks moocache -l 2030 > # echo '0 67108864 cache /dev/mapper/moocache-metadata /dev/mapper/moocache-blocks /dev/sda 512 1 writethrough default 4 random_threshold 4 sequential_threshold 32768' | dmsetup create moocache > # mkfs.ext4 /dev/mapper/moocache -U deadbeef-cafe-dead-beef-cafedeadbeef > > If I then run blkid, I only see this: > /dev/sdb: UUID="jlKkqi-L3W1-QQqf-7HKR-jmjU-GL79-qDOdvP" TYPE="LVM2_member" > /dev/sda: UUID="deadbeef-cafe-dead-beef-cafedeadbeef" TYPE="ext4" > > Curious -- it didn't find anything on /dev/mapper/moocache. e2fsck/mount also > see nothing, and dumping the first 256K shows zeroes. Sometimes it finds no > ext4 at all. > > If I create the cache in WB mode, I see that blkid finds the deadbeef fs on > /dev/sda and /dev/mapper/moocache, like I'd expect: > > /dev/sdb: UUID="9hYUEh-OOKT-KuqF-6eDy-2cEZ-2eEa-y17lhN" TYPE="LVM2_member" > /dev/mapper/moocache-blocks: UUID="deadbeef-cafe-dead-beef-cafedeadbeef" TYPE="ext4" > /dev/mapper/moocache: UUID="deadbeef-cafe-dead-beef-cafedeadbeef" TYPE="ext4" It looks like dm-cache issues the bio first to the origin device with bi_sector == N and bi_size == S, but then fails to reset these values when reissuing the bio to the cache device. Therefore, the second issue of the bio goes out with bi_size == 0 and bi_sector == N + (S >> 512), which is incorrect. I'll send a patch. --D > > --D > > > > > Mike Snitzer (2): > > dm cache: policy change version from string to integer set > > dm cache: policy ignore hints if generated by different version > > > > Mikulas Patocka (1): > > dm verity: avoid deadlock > > > > drivers/md/dm-bufio.c | 2 + > > drivers/md/dm-cache-metadata.c | 64 ++++++++-- > > drivers/md/dm-cache-metadata.h | 2 +- > > drivers/md/dm-cache-policy-cleaner.c | 7 +- > > drivers/md/dm-cache-policy-internal.h | 2 + > > drivers/md/dm-cache-policy-mq.c | 8 +- > > drivers/md/dm-cache-policy.c | 8 ++ > > drivers/md/dm-cache-policy.h | 2 + > > drivers/md/dm-cache-target.c | 169 +++++++++++++++++--------- > > drivers/md/dm-thin.c | 11 +- > > drivers/md/dm-verity.c | 39 +++++- > > drivers/md/persistent-data/dm-btree-remove.c | 46 +++---- > > 12 files changed, 252 insertions(+), 108 deletions(-) > > > > -- > dm-devel mailing list > dm-devel@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/dm-devel -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
