On 07.05.2015 16:14, Vasiliy Tolstov wrote: > 2015-05-07 17:06 GMT+03:00 Michal Privoznik <mprivozn@xxxxxxxxxx>: >> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list