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.
