Memory mapping: MAP_PRIVATE and msync()

[pehache]

As advised, I'm copying this post here

Hello,
When memory mapping a file with the MAP_PRIVATE flag, the modifications (writes)
only exist in memory and are not written back to the file.
According to the man pages, calling msync (3) on a such a mapping does NOT
"When the msync() function is called on MAP_PRIVATE mappings, any modified data
shall not be written to the underlying object and shall not cause such data to be
made visible to other processes"
https://linux.die.net/man/3/msync
So: is there a way to write the changes back to the file?
- mapping the file with MAP_PRIVATE
- make some modifications in memory only (fast) while keeping the original
version on disk (safe)
- at some point (when the user decides, and once the consistency of the changes
have been verified) writing the modifications to the disk
I'm pretty sure it exists some way or another, but I don't know how.

========================================
fd = open("aaa",O_RDWR);
p = mmap ( NULL
, n
, PROT_READ | PROT_WRITE
, MAP_PRIVATE | MAP_NORESERVE
, fd
, 0 );
// writing to p; the changes exist only in memory
void* p2 = mmap( NULL
, n
, PROT_READ | PROT_WRITE
, MAP_SHARED | MAP_NORESERVE
, fd
, 0 );
memcpy(p2,p,n); // copying everything from p to p2
msync(p2,n);
// unmap/remap p so it's ready for new changes
munmap(p,n);
p = mmap ( NULL
, n
, PROT_READ | PROT_WRITE
, MAP_PRIVATE | MAP_NORESERVE
, fd
, 0 );
========================================
- the whole content is copied, not only the changed content
- is this code legal? Is there any potential conflict between the 2 mapping,
with an undefined behavior?

[pehache]

Hello,

Hi, pehache

When memory mapping a file with the MAP_PRIVATE flag, the modifications
(writes) only exist in memory and are not written back to the file.

[snip]

So: is there a way to write the changes back to the file?

[snip]
The comp.unix.programmer newsgroup will be of better help for this sort
of question (it's not really on-topic for comp.lang.c).
But, of the top of my head; with my limited understanding of the unix
mmap() kernel call, the only ways to "write the changes" are to either
1) mmap(MAP_SHARED) and modify the mapped area, or
2) write() the mapped area back to the file.

I'm currenly using the first option in my code. Either way, the whole
mapped area is written back, even if there were only a few changes. I was
hoping there could be another way to wrtite back only the modified pages.

But, as I said, comp.unix.programmer will be of better help.

fu2

[James Kuyper]

...

But, as I said, comp.unix.programmer will be of better help.

fu2

Why does that advice annoy you? Why wouldn't you want to take your
question to the forum where people are best qualified to answer it?

[Keith Thompson]

Post by James Kuyper
...

But, as I said, comp.unix.programmer will be of better help.

fu2

Why does that advice annoy you? Why wouldn't you want to take your
question to the forum where people are best qualified to answer it?

I believe "fu2" refers to this header line in the article you're
replying to :
Followup-To: comp.unix.programmer

pehache: Apparently James thought "fu2" meant ... something else.

[pehache]

Post by Keith Thompson

Post by James Kuyper
...

But, as I said, comp.unix.programmer will be of better help.

fu2

Why does that advice annoy you? Why wouldn't you want to take your
question to the forum where people are best qualified to answer it?

I believe "fu2" refers to this header line in the article you're
Followup-To: comp.unix.programmer

That's correct.

Post by Keith Thompson
pehache: Apparently James thought "fu2" meant ... something else.

OK, sorry for the misunderstanding :( !

"fu2" is a routinely used abbreviation for "Followup-To" (and just that!)
on the fr.* hierarchy, and I thought it was kind of universal on all
hierarchies. Apparently it's not...

[Kenny McCormack]

In article <***@jntp>,
pehache <***@gmail.com> wrote:
...

Post by pehache
OK, sorry for the misunderstanding :( !

Nothing to be sorry about.

Post by pehache
"fu2" is a routinely used abbreviation for "Followup-To" (and just that!)
on the fr.* hierarchy, and I thought it was kind of universal on all
hierarchies. Apparently it's not...

It is fine.

This poster (James whatever) has a long history of weirdly misunderstanding
things. I wouldn't worry about it.

[pehache]

Post by James Kuyper
...

But, as I said, comp.unix.programmer will be of better help.

fu2

Why does that advice annoy you? Why wouldn't you want to take your
question to the forum where people are best qualified to answer it?

Uh? Following the advice is exactly what I've done: I have crossposted my
answer to c.u.p, with a fu2 positionned on it.