[dm-devel] Another cache target
Mark Hills
mark at pogo.org.uk
Sat Dec 22 18:50:09 UTC 2012
On Thu, 13 Dec 2012, Mike Snitzer wrote:
> On Thu, Dec 13 2012 at 8:16pm -0500,
> Darrick J. Wong <darrick.wong at oracle.com> wrote:
>
> > On Thu, Dec 13, 2012 at 04:57:15PM -0500, Mike Snitzer wrote:
> > > On Thu, Dec 13 2012 at 3:19pm -0500,
> > > Joe Thornber <ejt at redhat.com> wrote:
> > >
> > > > Here's a cache target that Heinz Mauelshagen, Mike Snitzer and I
> > > > have been working on.
> > > >
> > > > It's also available in the thin-dev branch of my git tree:
> > > >
> > > > git at github.com:jthornber/linux-2.6.git
[...]
> > Also, I found a bug when using the mru policy. If I do this:
>
> Pretty sure you'd be best served to focus on the code Joe posted. Maybe
> best to clone my github tree and start with my 'dm-for-3.8' branch. And
> then apply all the patches Joe posted.
I also tried the other policies before reading the comment above. I wanted
to see data more agressively copied to the cache device to see what
happened.
Specifically, I tested lru and had an interesting problem. One which
suggests it is not specific to the policy, but possibly to trigger quickly
with it.
When mounting an ext4 filesystem with lru:
attempt to access beyond end of device
sdc1: rw=0, want=625140480, limit=625140400
(though an fsck completed fine)
Possibly the outcome of lru trying to cache the final block of the
filesystem? Where, I presume, mq would not try and do this unless this
block became a hot-spot.
The table used was:
0 625140400 cache /dev/sdb1 /dev/sdb2 /dev/sdc1 256 1 writethrough lru 0
I tried both with a cache prepared using mq, and a clean cache -- where
sdb1 and sdb2 have the first 4k blanked.
The code is the current dm-devel-cache (b910ac06) from
git://github.com/snitm/linux.git
> I'd stick to the "default" policy -- aka "mq".
I tested mq, and had no problems whatsoever with stability (except where I
modified the backing device and forgot to clear the cache.) I didn't yet
do any performance test yet.
I look forward to being able to use this for general workstation use, and
as storage for a simple (but large) hash-table database for an
application.
Great stuff, thanks!
--
Mark
More information about the dm-devel
mailing list