[ENBD] need help

[Peter T. Breuer]

"A month of sundays ago Manish Kumar Srivastava wrote:"
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Apply the patch available at
> 
> http://lists.community.tummy.com/pipermail/enbd/2001/000648.html
> 
> This should solve your problem.

Thanks.

> >-----Original Message-----
> >From: prashant kharche [mailto:pdkharche@hotmail.com]
> >Sent: Tuesday, March 05, 2002 1:27 PM
> >To: enbd@lists.community.tummy.com
> >Subject: [ENBD] need help
> >
> >
> >Hi!
> >i have nbd-2.4.26 .. im trying to compile this package..
> >my kernel version is 2.4.17
> >but im getting error as
> >/nbd-2.4.26/linux/drivers/block/nbd.c: In function `buffer...
> >/nbd-2.4.26/linux/drivers/block/nbd.c:1977: warning: implicit 
> >declaration of 
> >function `mark_buffer_protected'
> >
> >please tell me whats wrong here...

Isn't it obvious? The kernel lost this function round about kernel
2.4.11. You can move up to nbd-2.4.16a which has a different driver,
or you can comment out the offending line, or you can apply the patch
(which provides an approximate substitute for mark_buffer_protected).

It doesn't look mysterious to me :-(

In any case, please pay attention also in recent kernels to the
/proc/sys/vm/bdflush line. The kernel VM changed and now is going into
a "synchronous mode" too early for correct behaviour in low-memory
machines (<= 128M).

  nbd:/usr/oboe/ptb% cat /proc/sys/vm/bdflush 
  40      0       0       0       200     3000    60      0       0
  ^                                               ^
  |                                               |
% onset async                                    % onset SYNC
dirty buffer                                     dirty buffer flush
flush


These numbers are too close together and the upper one is too low.
I would choose something like 10% and 90% (or 100%). You can rewrite
them to your taste.


The kernel starts flushing buffers when 40% are dirty in the above
scenario. It doesn't pass any to the enbd driver before that. If
you are writing to the nbd device, this number can probably be reached
in fraction of a second or so. Only 20% dirty buffers later the kernel
goes into sync mode - it won't allocate a buffer until it gets rid of
one. This is wrong for nbd. To empty a buffer aimed at nbd to the net,
you need tcp buffers.

You should push these numbers as far apart as possible, and probably
never go into sync mode - you are almost certainly dead if you get
there, it seems. 

I don't understand exactly the VM hysteresis involved, but experiments
show behaviour consistent with what I have just described. If the
numbers are far apart, you get smooth continuous flow under constant
pressure. If they are close you get fast, stop, fast, stop, and one of
those stops may be deadly.

Furthermore, it seems at the moment that at the top of the pressure
curve, the kernel actually discards buffers. I don't have an
explanation, but I was able to force requests to present themselves
at the device which said they contained data, but in fact they
had a NULL first bh pointer. I'm still investigating .. but the
problem goes away when I adjust VM as indicated. And the machine
crashes when I don't, so I know which I prefer ...


Peter