Re: [Nbd] Yet another NBD server out there

[Wouter Verhelst <w@...112...>]

On Sat, Mar 09, 2013 at 11:36:22PM +0100, Michal Belczyk wrote:
> On Sat, Mar 09, 2013 at 02:17:19PM +0100, folkert wrote:
> > >   http://code.belo.io/bnbd/
> > 
> > Some comments: it fails silently. You need to dig in syslog to find out
> > it could not write its PID-file. Imho that should be shown on the
> > console.
> 
> Yeah, perhaps it should, but for now one has to take a look in the logs
> or use -d option to make it stay foreground and display the logs on the
> console (when specified twice the config file option syslog_priority is
> ignored and all logs up to the debug level show up -- see
> scripts/bnbd-server.sh).
> 
> 
> > It also would just disappear without any messages in syslog.
> 
> Now this looks like a bug to me -- could you please file an issue for it
> on the project's bitbucket site and provide more details?
> Much appreciated!
> I think we should discuss this in private as this mailing list is
> definitely not the right place to solve any bnbd-server issues...

why not?

[...]
> > > It is a true network _block_ device, not a network _memory_ device as it
> > > does not take any advantage of the buffer cache on the data origin
> > > server.
> > 
> > What's the advantage of that?
> 
> There are both advantages and disadvantages -- it all depends on the use
> case and it all depends on what you expect from a block device...
> I do not expect more than the underlying physical device's raw
> performance,

I haven't looked at the code, but can you explain how this differs from
the "sync" option in nbd-server?

> I do expect that buffer cache flushes on the client side
> actually hit at least the underlying device's write cache (nearly sync
> writes on the server side),

With the FUA patch (which finally has been accepted into Linux proper),
this will happen; when the client side does an explicit buffer cache
flush, this will be finished with an FUA call, which will cause an
fsync() on the server side.

The effect will be the same, except that the system will be better,
performance wise.

> specifically when client-side applications call fsync(), and I do
> expect the server not to block for a long time when the server-side VM
> will block it while flushing data to disk, causing clients to time
> out...

Have you ever seen that to be a problem in practice?

[...]
> I have never claimed that bnbd-server is a replacement for the original
> nbd-server -- they are both two different beasts... and mine is just a
> different approach to the whole NBD thing...

Not really, in my opinion.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.