[linux-lvm] bcache and dm targets (specifically lvm)

[Kent Overstreet]

On Sun, Mar 04, 2012 at 09:21:40AM -0500, Mike Snitzer wrote:
> On Fri, Mar 02 2012 at  9:28pm -0500,
> Joseph Glanville <joseph.glanville at orionvm.com.au> wrote:
> 
> > Ahh!
> > 
> > I didn't know LVM had a device type lookup table. You can see if you
> > look further that it also reads new types from the lvm.conf file.
> > Adding this line to lvm.conf fixes the problem:
> > 
> > types = [ "bcache", 16 ]
> >
> > I would imagine if merged it would be added to the internal compiled in table.
> 
> Assuming bcache devices are partitionable 16 would be used (like patch
> below), if they aren't then 1 would be used.

Thanks... any insight into what that table is for?

> Kent,
> 
> I know you were frustrated with DM in the past and that is why you
> created your own device type.

That'd be accurate :)

> I'll be looking much closer at bcache in the next week or so.  I'm
> starting to work on a DM-based caching target... it will re-use the
> drivers/md/persistent-data/ infrastructure we've established as part of
> the DM Thin Provisioning target.

Interesting... I'm also working on thin provisioning in bcache. It's
functional now but not production ready, pending the copying garbage
collector which I'm working on now.

For now it'll only be suitable for flash though, as it uses the same
allocation code as the caching code and assumes efficient random reads.

> Anyway, even if bcache remains to be a standalone (non-DM) block device
> in the future I'll have a look at it with an eye toward code sharing
> that might allow other caching layers to build on a common layer.  Even
> if the common code is a policy engine I think it'd be cool to allow
> sharing of policy across caching targets.

I've been working on making bcache's b+tree and other code more modular
for building other things around it. It's gotten quite fast, capable of
somewhere north of a million lookups per second.

> That said I'm also open to porting bcache to DM... but time will tell.
> I'll grab the latest bcache code and jump on the linux-bcache list and
> we can take it one step at a time.

I'm not averse to a dm interface for bcache (though I don't really see
the usefulness myself)... I could definitely spend some time walking you
through code and improving documentation, if you're interested.