On 07.05.2015 16:14, Vasiliy Tolstov wrote:
2015-05-07 17:06 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>:
The main benefit of using iohelper is that we have aligned reads from disks and thus can use O_DIRECT flag. So if anything, any compression must be put in between iohelper and the daemon which then resends data to clients.
but if iohelper after read data from disk compress it, does it suitable?
Yes, it's suitable.
Unfortunately, we don't have a field in the API signature that can be used to select desired algorithm. We have @flags which could be used to enable compression. Which algorithm to use can be set in a config file (libvirtd.conf seems most suitable).
May be encode in flags compressor ? So we don't need additional entry in config file and without needed flag iohelper does not compress at all ?
This is what I'm trying to avoid: having a flag per every compression algorithm out there in wildness. Flags are meant to slightly change behaviour of a function, not to encode an enum. It's a waste too: to encode say 4 algorithms as flags you need 4 bits, while in reality you'd need only 2. The more algorithms we introduce the more bits from @flags are consumed, leaving less space for something more useful. Also, I guess algorithms will not be chained (it does not make much sense either), so flags would need to be mutually exclusive. Therefore my initial approach, with just a single flag to enable compression, and leave algorithm to be selected somewhere else. Michal