[dm-devel] Refcounting (and other) questions

[Kent Overstreet]

I got bcache functioning with dm... it's buggy, but it runs. _Much_ 
thanks to akg for educating me, I now have a vague idea of how dm is 
structured.

My most immediate problem is what to do in the target destructor. It 
looks like when the destructor returns, the dm_target is gone. This an 
issue if I use dm_get_device() and dm_put_device() - if writeback is 
going on in the background I can't just close the backing device 
arbitrarily, I've got refcounting that I need to use.

So I could just not use dm_get_device and instead use 
open_bdev_exclusive - like I do for caches, but I was hoping to get some 
input on the subject.

I may have to do that anyways; the way bcache + dm is structed currently 
is basically a stopgap. I'm planning on starting on volume management + 
thin provisioning soon; what this means is that it doesn't really make 
sense for userspace to arbitrarily create and remove targets. Rather, 
the kernel knows what volumes are available (and their sizes and labels).

It seems to me that there's going to be some moderately painful... model 
mismatch if I try to do this with device mapper. OTOH, I've heard 
references of some standard interface for managing volumes that's in the 
works; I haven't been able to find out anything more about it but it 
sounds like it might be relevant, if someone wanted to point me at it.

Last question: Right now I'm doing
# dmsetup foo
0 10000 bcache /dev/vdb
^D

for testing. The problem is userspace has no idea how big the target 
should be; that's not just dependent on the size of the backing device 
but the start of actual data (for alignment, mainly) is stored in the 
superblock which the kernel reads. I can't be the first person to run 
into this issue - how should bcache convey the actual size of the target 
to dm/somewhere where it can be useful?