CCing Zack Cornelius. On Wed, Jun 14, 2017 at 05:29:55PM -0300, Eduardo Habkost wrote: > This series adds a new "persistent" option to > memory-backend-file. The new option it will be useful if > somebody is sharing RAM contents on a file using share=on, but > don't need it to be flushed to disk when QEMU exits. > > Internally, it will trigger a madvise(MADV_REMOVE) or > fallocate(FALLOC_FL_PUNCH_HOLE) call when the memory backend is > destroyed. > > To make we actually trigger the new code when QEMU exits, the > first patch in the series ensures we destroy all user-created > objects when exiting QEMU.
So, before sending a new version of this, we need to clarify one thing: why exactly unlink()+close() wouldn't be enough to avoid having data unnecessarily flushed to the backing store and make the new option unnecessary? I would expect close() to not write any data unnecessarily if there are no remaining references to the file. Why/when this is not the case? -- Eduardo
