I'm interested in setting up a FUSE-like infrastructure in userspace that will use NBD and allow people to develop virtual block devices without having to write any kernel code. For example, one of the things I would like to do is create a deduplicating block device, and it would be easiest if I could prototype it in userspace. The setup would be fairly simple and just involve a server that speaks NBD's protocol and implements whatever kind of block device you want it to be.
I have read about similar attempts and I know that there are deadlock issues associated with running NBD as a client and server on the same machine. So I was wondering if the following measures would eliminate the deadlock problem: 1. Run a separate kblockd thread for NBD. (This is suggested in the README.) 2. Set /sys/class/bdi/<nbd device...>/max_ratio to something relatively small. This should prevent the NBD device from using more than a small fraction of the writeback cache. (I believe this addresses the problem mentioned in this thread: http://comments.gmane.org/gmane.linux.drivers.nbd.general/44 ) If I understand correctly, these two measures should guarantee that even if the thread writing out the cache for an NBD device gets hung, another thread will eventually make progress freeing up memory by writing out dirty pages for other devices. I would appreciate any thoughts on whether this sounds like a plausible approach. Thank you. Sincerely, Adam Cozzette -- Adam Cozzette Harvey Mudd College Class of 2012 ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
