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 way? 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. Thanks -- Mark -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
