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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ