linux-kernel - Re: dm-cache not writing out cache metadata at reboot?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20130508220526.GA24132@redhat.com>
Date:	Wed, 8 May 2013 18:05:26 -0400
From:	Mike Snitzer <snitzer@...hat.com>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	Joe Thornber <thornber@...hat.com>,
	device-mapper development <dm-devel@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: dm-cache not writing out cache metadata at reboot?

On Wed, May 08 2013 at  5:48pm -0400,
Darrick J. Wong <darrick.wong@...cle.com> wrote:

> Hi,
> 
> So I've been watching the hit/miss counters in dmcache and I've noticed a
> couple of things that look like errors to me:
> 
> First, I noticed that if I reboot the system, neither cache_postsuspend nor
> cache_dtr get called.  This might simply be expected behavior, but it means
> that the in-memory superblock structure doesn't get written out to disk upon
> reboot.  Just to be sure, I put a printk into __commit_transaction.  It prints
> out for 'dmsetup info' and 'dmsetup remove' but nothing at reboot.

We don't have reboot notifiers that auto-magically tear down an
artbitrary DM stack.  Typically the device shutdown includes unmounting
filesystems, stopping LVM (which tears down DM devices, etc).

So given that we don't have any userspace LVM2 support for dm-cache yet
I'm not surprised by this.  In fact it is expected.
 
> Second, cache_status calls dm_cache_commit, which writes out a superblock to
> the metadata device.  However, there's no call to save_stats to copy the
> current values of the counters out to the disk's copy prior to calling
> dm_cache_commit.  Therefore, we seem to be writing out stale copies of
> superblock fields.
> 
> The second one seems fixable with the attached patch

I'll defer to Joe on this but I think sync_metadata() is pretty heavy to
be doing every 'dmsetup info'.  BTW, with just dm_cache_commit() the
superblock fields aren't stale; only the on-disk hints are.

Mike
--
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/