* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Wed, May 11, 2022 at 07:31:45PM +0200, Claudio Fontana wrote: > > That's great, I love when things are simple. > > > > If indeed we want to remove the copy in libvirt (which will also mean > > explicitly fsyncing elsewhere, as the iohelper would not be there anymore > > to do that for us on image creation), > > with QEMU having a "file" protocol support for migration, > > > > do we plan to have libvirt and QEMU both open the file for writing > > concurrently, with QEMU opening O_DIRECT? > > For non-libvirt users, I expect QEMU would open the > file directly . For libvirt usage, it is likely > preferrable to pass the pre-opened FD, because that > simplifies file permission handling. > > > The alternative being having libvirt open the file with > > O_DIRECT, write some libvirt stuff in a new, O_DIRECT- > > friendly format, and then pass the fd to qemu to migrate to, > > and QEMU sending its new O_DIRECT friendly stream there. > > Yep. > > > In any case, the expectation here is to have a new > > "file://pathname" or "file:://fdname" as an added feature in QEMU, > > where QEMU would write a new O_DIRECT friendly stream > > directly into the file, taking care of both optional > > parallelization and compression. > > I could see several distinct building blocks > > * First a "file:/some/path" migration protocol > that can just do "normal" I/O, but still writing > in the traditional migration data stream > > * Modify existing 'fd:' protocol so that it fstat()s > and passes over to the 'file' protocol handler if > it sees the FD is not a socket/pipe
We used to have that at one point. > * Add a migration capability "direct-mapped" to > indicate we want the RAM data written/read directly > to/from fixed positions in the file, as opposed to > a stream. Obviously only valid with a sub-set > of migration protocols (file, and fd: if a seekable > FD). This worries me about how you're going to cleanly glue this into the migration code; it sounds like what you want it to do is very different to what it currently does. Dave > * Add a migration capability "bypass-cache" to > indicate we want O_DIRECT to bypass host I/O > cache. Again limited to some migration protocols > > > With regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
