[dm-devel] RFC: dm-ssdcache

Mark Hills mark at pogo.org.uk
Sat Mar 17 19:47:06 UTC 2012

On Fri, 16 Mar 2012, Hannes Reinecke wrote:

> Hi all,
> to through some more confusion in an already heated debate, here is
> the 'dm-ssdcache' module I recently wrote.
> And held a talk about at LinuxCon Europe 2011 :-)
> Upon request I'll be generating a proper patch ...
> Not saying it's perfect, and surely doesn't have all the nifty
> features bcache has, but it should serve as a 'minimal'
> implementation. And probaly will start yet another discussion,
> if nothing else.
> So, comments etc are welcome.

Thanks for sharing this. I gave it a try with mixed but promising 
resulting. I'll share my observations in case they are useful.

Writethrough mode worked as expected, as did 'readcache'. But I found the 
caching would stop after a short time; data already in the cache was read 
from there, but no new data written. dmesg no longer prints "flush start", 
"flush done", but no other indication; possibly some lock is taken in some 

It took me a while to work out how to switch to LRU behaviour, as I had to 
give the number of option arguments, for reference here it is:

  dmsetup create test --table "0 625137282 ssdcache /dev/sdc1 /dev/sdb1 options 1 lru"

In writeback I found I was quickly getting ext4 reports of corruption. 
Even just between formatting the device and using it. Possibly it 
by-passes the cache a little too readily under some reasons (eg. large bio 
size) when data is in the cache?

In all cases I zeroed the front of the cache device before use, but I 
couldn't see quickly from the code whether the cache device is intended to 
be persistent and if I need a better way to initialise it, I assume not?

"dmsetup remove" seems to take along time (several minutes), not spinning 
on CPU or disk. But it does eventually complete. Possibly this is linked 
to the non-caching issue and some kind of lock. But then that doesn't 
explain why it eventually completes.



More information about the dm-devel mailing list