[dm-devel] Newbie questions

[Alec Thomas]

Hi Joe,

> No you will need to stack the devices, this is quite deliberate.  The
> overhead is very small.  Write a target that 1 thing, and 1 thing only
> ;)

Okay, fair enough...I had suspected this was the case from looking at
the code. Simple is good :)

> This is a hard problem, since you have to be extremely careful to
> avoid deadlocks due to memory allocation failure.  eg. if the the
> physical memory is full, and so some io gets triggered to relieve this
> presure, which goes through your target, which calls some userland
> code which has been paged out ...

Right, that makes sense. I've been looking at the nbd code and it
appears the user-space stuff is just for control information; the
actual transfer of blocks over the network takes place in kernel space.

So, from my understanding, to make a reliable user-space daemon you
would need to mlock every page used by the user-space daemon. Code,
data, everything.

What a dilemma...the advantages of user-space are many; integration with
existing cluster infrastructure, being able to leverage existing
libraries, etc.

> 
> Communication with userland is envisaged as being a very rare
> occurance, certainly not for every io.  You can use the status command
> to get back some information from your target, and the
> dm_table_event() function can be used to indicate to userland that the
> status has changed.

Right, I noticed the status stuff, but there didn't seem to be a
"device-mapper" way to actually communicate with the target once it is
up and running? I guess creating a /proc entry or another device node
specifically for communication is the only way?

Alec

-- 
Evolution: Taking care of those too stupid to take care of themselves.