[Nbd] Deadlock Issues with Local NBD Server

[Adam Cozzette <acozzette@...946...>]

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