[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] Deadlock Issues with Local NBD Server



On Wed, Sep 28, 2011 at 03:51:07PM +0200, Goswin von Brederlow wrote:
> Adam Cozzette <acozzette@...946...> writes:
> 
> > 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'm verry interested in that too. My solution at the moment is running
> nbd-server in a virtual machine to make it not local.

That sounds to me like it will work, but only if the virtual machine has enough
memory preallocated to it that it can serve nbd requests without running out of
memory. (I don't know much about virtualization so I don't know if each guest
has memory set aside for it or not. If it has to ask the hypervisor for more
memory in order to serve nbd requests then I think there may be a problem.)

> But maybe NBD is the wrong thing for this. For a strictly local setup
> there i no reason to pipe all data through the tcp/ip stack. Maybe we
> should develope a BUSE (Block device in Uer SpaceE) just like fuse and
> cuse do for filesystems and character devices already.

Actually someone has already written something called ABUSE (a block device in
user space) for the Linux kernel:
http://lkml.indiana.edu/hypermail/linux/kernel/0907.3/00830.html
But the consensus among other kernel developers seemed to be that it was too
similar to nbd. And I think the deadlock problems are pretty much the same.

-- 
Adam Cozzette
Harvey Mudd College Class of 2012



Reply to: