Re: [PATCH RFC 0/9] qemu: Support mapped-ram migration capability

On Thu, Jun 13, 2024 at 04:43:14PM -0600, Jim Fehlig via Devel wrote: They might seem tiny bit hacky, but it's not that big of a deal I think. You could eliminate two conditions by making the first FD always non-direct (as in either there is no BYPASS_CACHE or it's already wrapped by the I/O helper), but it would complicate other things in the code and would get even more hairy IMHO. By the time I looked at this series the direct-io work has already went in, but there is still the need for the second descriptor to do some unaligned I/O. From the QEMU patches I'm not sure whether you also need to set the direct-io migration capability/flag when migrating to an fdset. Maybe that's needed for migration into a file directly. I was wondering whether it would make sense to use user-space block I/O, but we'd have to use some compression on a block-by-block basis and since you need to be able to compress each write separately, that means you might just save few bytes here and there. And on top of that you'd have to compress each individual block and that block needs to be allocated as a whole, so no space would be saved at all. So that does not make sense unless there is some new format. And compression after the save is finished is in my opinion kind of pointless. You don't save time and you only save disk space _after_ the compression step is done. Not to mention you'd have to uncompress it again before starting QEMU from it. I'd be fine with making users choose between compression and mapped-ram, at least for now. They can compress the resulting file on their own. That's fine and even better. It saves space, the only thing that everyone needs to keep in mind is to treat it as a sparse file. The other option for the space saving would be to consolidate the streamed changes in the resulting file, but for little to no gain. The mapped-ram is better. Some more teeny tiny comments in two patches will follow. Martin