Most importantly, we won't be corrupting/touching the original file in any
case, because it is R/O.
If we really want to be careful, we could clue that behavior to compat
machines. I'm not really sure yet if we really have to go down that path.
Any other alternatives? I'd like to avoid new flags where not really
required.
I was just thinking of a new flag. :) So have you already discussed that
possibility and decided that not a good idea?
Not really. I was briefly playing with that idea but already struggled
to come up with a reasonable name :)
Less toggles and just have it working nice, if possible.
The root issue to me here is we actually have two resources (memory map of
the process, and the file) but we only have one way to describe the
permissions upon the two objects. I'd think it makes a lot more sense if a
new flag is added, when there's a need to differentiate the two.
Consider if you see a bunch of qemu instances with:
-mem-path $RAM_FILE
On the same host, which can be as weird as it could be to me.. At least
'-mem-path' looks still like a way to exclusively own a ram file for an
instance. I hesitate the new fallback can confuse people too, while that's
so far not the major use case.
Once I learned that this is not a MAP_SHARED mapping, I was extremely
confused. For example, vhost-user with "-mem-path" will absolutely not
work with "-mem-path", even though the documentation explicitly spells
that out (I still have to send a patch to fix that).
I guess "-mem-path" was primarily only used to consume hugetlb. Even for
tmpfs it will already result in a double memory consumption, just like
when using -memory-backend-memfd,share=no.
I guess deprecating it was the right decision.
But memory-backend-file also defaults to "share=no" ... so the same
default behavior unfortunately.
Nobody may really rely on any existing behavior of the failure, but
changing existing behavior is just always not wanted. The guideline here
to me is: whether we want existing "-mem-path XXX" users to start using the
fallback in general? If it's "no", then maybe it implies a new flag is
better?
I think we have the following options (there might be more)
1) This patch.
2) New flag for memory-backend-file. We already have "readonly" and
"share=". I'm having a hard time coming up with a good name that really
describes the subtle difference.
3) Glue behavior to the QEMU machine
For 3), one option would be to always open a COW file readonly (as
Thiner originally proposed). We could leave "-mem-path" behavior alone
and only change memory-backend-file semantics. If the COW file does
*not* exist yet, we would refuse to create the file like patch 2+3 do.
Therefore, no ftruncate() errors, and fallocate() errors would always
happen.
What are your thoughts?
[...]
[I'm curious at what point a filesystem will actually break COW. if it's
wired up to the writenotify infrastructure, it would happen when actually
writing to a page, not at mmap time. I know that filesystems use writenotify
for lazy allocation of disk blocks on file holes, maybe they also do that
for lazy allocation of disk blocks on COW]
I don't know either, but it definitely looks more promising and reasonable
if the CoW only happens until being written, rather than being mapped RW.
That would be my best guess. But then, we have multiple pagecache pages
point at the same disk block until COW happens ... maybe that's how it
already works. Once I have some spare time, I might play with that.
--
Cheers,
David / dhildenb
