>> >> I mean, that would be fundamentally broken, because the fsync() would >> corrupt the file. So I assume in a sane environment, the dst could only >> have stale clean pagecache pages. And we'd have to get rid of these to >> re-read everything from file. > > In case of write back cache mode, we could still have stale dirty > pages at the destination > host and destination fsync is not the right thing to do. We need to > invalidate these pages > (Can we invalidate dirty pages resident in page cache with > POSIX_FADV_DONTNEED as > well?) man pages say, we cannot (unless i misunderstood it). >
I think you'd have to fsync + POSIX_FADV_DONTNEED. But I am still confused how we could end up with dirty pagecache pages on the destination. In my opinion, there should only be clean pagecache pages -- can someone enlighten me? :) >> >> IIRC, an existing mmap of the file on the dst should not really be >> problematic *as long as* we didn't actually access file content that way >> and faulted in the pages. So *maybe*, if we do the POSIX_FADV_DONTNEED >> on the dst before accessing file content via the mmap, there shouldn't >> be an issue. Unless the mmap itself is already problematic. > > mmap with shared=ON, might result in stale dirty page cache pages? But only if actually accessing memory, especially writing to it, no? > >> >> I think we can assume that once QEMU starts on the dst and wants to mmap >> the file that it's not mapped into any other process yet. vhost-user >> will only mmap *after* being told from QEMU about the mmap region and >> the location in GPA. > > maybe we have an old stale dirty page cache page even if there no mmap process > alive before mmaping virtio-pmem backend file in destination? But how could that happen in a sane environment? As I said, any writeback on that file from the destination would actually corrupt the file that has been used+modified on the source in the meantime, no? -- Thanks, David / dhildenb
