This patch allows a Network Block Device to be mounted locally
(nbd-client to nbd-server over 127.0.0.1).
It creates a kthread to avoid the deadlock described in NBD tools
documentation. So, if nbd-client hangs waiting for pages, the kblockd
thread can continue its work and free pages.
I have tested the patch to verify that it avoids the hang that occurs
when writing to a localhost nbd connection. I have also tested to verify
that no performance degradation results from the additional thread and
queue.
Patch originally from Laurent Vivier.
Thanks,
Paul
Hi!
> This patch allows a Network Block Device to be mounted locally (nbd-client
> to nbd-server over 127.0.0.1).
>
> It creates a kthread to avoid the deadlock described in NBD tools
> documentation. So, if nbd-client hangs waiting for pages, the kblockd
> thread can continue its work and free pages.
What happens if your new kthread blocks on memory allocation?
Pavel--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
>> This patch allows a Network Block Device to be mounted locally (nbd-client
>> to nbd-server over 127.0.0.1).
>>
>> It creates a kthread to avoid the deadlock described in NBD tools
>> documentation. So, if nbd-client hangs waiting for pages, the kblockd
>> thread can continue its work and free pages.
>
> What happens if your new kthread blocks on memory allocation?
Well, we expect that. The reason for the new thread is so that it hangs,
rather than kblockd hanging (which on a UP system brings all I/O to a
halt). As long as kblockd can continue making progress, we eventually
free up memory and then NBD can finish its requests, too.
--
Paul
On Mon 2008-03-10 13:26:34, Paul Clements wrote:
> Pavel Machek wrote:
>
>>> This patch allows a Network Block Device to be mounted locally
>>> (nbd-client to nbd-server over 127.0.0.1).
>>>
>>> It creates a kthread to avoid the deadlock described in NBD tools
>>> documentation. So, if nbd-client hangs waiting for pages, the kblockd
>>> thread can continue its work and free pages.
>>
>> What happens if your new kthread blocks on memory allocation?
>
> Well, we expect that. The reason for the new thread is so that it hangs,
> rather than kblockd hanging (which on a UP system brings all I/O to a
> halt). As long as kblockd can continue making progress, we eventually free
> up memory and then NBD can finish its requests, too.
...unless all the memory is in dirty buffers for nbd, and nbd server
is swapped out or something?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, Mar 11, 2008 at 11:09:04AM +0100, Pavel Machek wrote:
> On Mon 2008-03-10 13:26:34, Paul Clements wrote:
> > Pavel Machek wrote:
> >
> >>> This patch allows a Network Block Device to be mounted locally
> >>> (nbd-client to nbd-server over 127.0.0.1).
> >>>
> >>> It creates a kthread to avoid the deadlock described in NBD tools
> >>> documentation. So, if nbd-client hangs waiting for pages, the kblockd
> >>> thread can continue its work and free pages.
> >>
> >> What happens if your new kthread blocks on memory allocation?
> >
> > Well, we expect that. The reason for the new thread is so that it hangs,
> > rather than kblockd hanging (which on a UP system brings all I/O to a
> > halt). As long as kblockd can continue making progress, we eventually free
> > up memory and then NBD can finish its requests, too.
>
> ....unless all the memory is in dirty buffers for nbd, and nbd server
> is swapped out or something?
Note that I'm not a kernel hacker, so might be terribly mistaken here...
but I feel I should point out that this patch solves the issue that no
two block devices can flush their dirty buffers at the same time.
Without this patch, you can't write to a _filesystem_ on an NBD device
if that's connected to a server on the localhost. You are correct that
this does not solve the deadlock in swapping to NBD devices, but that's
not the only existing deadlock issue in NBD to localhost...
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Hi!
> > >>> This patch allows a Network Block Device to be mounted locally
> > >>> (nbd-client to nbd-server over 127.0.0.1).
> > >>>
> > >>> It creates a kthread to avoid the deadlock described in NBD tools
> > >>> documentation. So, if nbd-client hangs waiting for pages, the kblockd
> > >>> thread can continue its work and free pages.
> > >>
> > >> What happens if your new kthread blocks on memory allocation?
> > >
> > > Well, we expect that. The reason for the new thread is so that it hangs,
> > > rather than kblockd hanging (which on a UP system brings all I/O to a
> > > halt). As long as kblockd can continue making progress, we eventually free
> > > up memory and then NBD can finish its requests, too.
> >
> > ....unless all the memory is in dirty buffers for nbd, and nbd server
> > is swapped out or something?
>
> Note that I'm not a kernel hacker, so might be terribly mistaken here...
>
> but I feel I should point out that this patch solves the issue that no
> two block devices can flush their dirty buffers at the same time.
> Without this patch, you can't write to a _filesystem_ on an NBD device
> if that's connected to a server on the localhost. You are correct that
> this does not solve the deadlock in swapping to NBD devices, but that's
> not the only existing deadlock issue in NBD to localhost...
Same issue with swapping probably exists with dirty block
writeout... swapoff -a, and filesystem becomes very similar to swap.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
pomozte zachranit klanovicky les: http://www.ujezdskystrom.info/