On 07.05.2015 16:14, Vasiliy Tolstov wrote:
2015-05-07 17:06 GMT+03:00 Michal Privoznik
<mprivozn(a)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