Re: [Libguestfs] LZO compression for NBD ?

[adding libguestfs list, for nbdkit reference below] On 10/4/18 8:39 AM, Stefan Fröberg wrote: 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