[Libguestfs] LZO compression for NBD ?

[Eric Blake]

[adding libguestfs list, for nbdkit reference below]

On 10/4/18 8:39 AM, Stefan Fröberg wrote:
> Hello.
> Is it possible to improve NBD throughtput with LZO compression ?

As in, have a way for the client and server to negotiate that both 
understand an LZO extension, at which point the client can request a 
read or write with a flag set to mark that the data is LZO-compressed, 
for less network traffic but higher CPU usage between the client and server?

The idea might have merit, you're certainly welcome to propose it as an 
extension (we can help with word-smithing the extension into the NBD 
specification and ideas of the best way to negotiate the feature); it is 
also helpful if you also plan on showing a reference implementation of 
both a server and client implementing the extension.

Would it always have to be LZO compression, or would it be smarter to 
have the negotiation phase pass a list of names of compression 
algorithms, where clients and servers can both advertise their list of 
algorithms they support, and then settle on one that is common to both 
sides?  Is it better to request that ALL read/write transactions 
automatically be compressed by the negotiated algorithm, or only the 
specific transactions where the client requests compression (after all, 
the overhead of compressing a small transaction might be worse than just 
sending the data directly; while the benefits of increased CPU times for 
compression/decompression are more likely to matter for large 
transactions where the transmission time becomes the bottleneck).

On a different track, you may want to try some experiments with LZO 
compression by using nbdkit.  Assuming that the real bottleneck that you 
are trying to speed up is TCP/IP traffic, while local NBD connections 
over a Unix socket are much faster, you could replace:

client => uncompressed over TCP/IP => server

with

client => uncompressed over Unix => nbdkit with custom plugin => 
compressed over TCP/IP => custom wrapper => server

where you write a wrapper on the server side to perform the LZO 
compression (nbdkit does not yet provide a plugin library for easy 
writing of a client, but maybe it should), then a plugin on the client 
side that can interpret your LZO-compressed stream on the client side. 
nbdkit already comes with a plugin that can read from .xz files 
(slightly different from compressing individual transactions). But the 
point remains that if what you are trying to design is an alternative 
network stream with compressed data while still having a traditional NBD 
interface once the data is local, then using nbdkit or other 
intermediaries as boundary points can prove useful.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org