COW pages and FL_PUNCH_HOLE

COW pages and FL_PUNCH_HOLE

[Matthew Wilcox]

I don't see a discussion of this anywhere ... and I thought linux-api was
the right place to ask.

I see holepunch as being "like ftruncate() but for the middle of the file".
So it feels weird to me that MAP_PRIVATE behaves differently; truncate
will rip out COWed pages, but holepunch won't.  Is there a good reason for
this behaviour, and is it too late to change?

Re: COW pages and FL_PUNCH_HOLE

[Darrick J. Wong]

On Tue, Dec 05, 2017 at 07:34:01AM -0800, Matthew Wilcox wrote:
> 
> I don't see a discussion of this anywhere ... and I thought linux-api was
> the right place to ask.
> 
> I see holepunch as being "like ftruncate() but for the middle of the file".
> So it feels weird to me that MAP_PRIVATE behaves differently; truncate
> will rip out COWed pages, but holepunch won't.  Is there a good reason for
> this behaviour, and is it too late to change?

I see truncate as 'change this global size property of a file' which is
why we'd rip out COWed pages past the new EOF, whereas punch hole is
more akin to writing zeroes to a certain file range.  This shouldn't
affect private mappings that a process has already written to and
therefore gotten its own copy...

...but the manpage says "It is unspecified whether changes made to the
file after the mmap() call are visible in the mapped region." so I guess
either way is fine?  Though who knows what now depends on the current
behavior, so changing it would be hard.

Thinking about this more, it seems weird that if you punch a range
starting before the cow'd page and ending after the cow'd page that a
reread of that part of the shared mapping now gets you zeroed pages
except for the cow'd page which is still intact...?

<shrug>

--D

> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: COW pages and FL_PUNCH_HOLE

[Matthew Wilcox]

On Tue, Dec 05, 2017 at 09:24:51AM -0800, Darrick J. Wong wrote:
> On Tue, Dec 05, 2017 at 07:34:01AM -0800, Matthew Wilcox wrote:
> > 
> > I don't see a discussion of this anywhere ... and I thought linux-api was
> > the right place to ask.
> > 
> > I see holepunch as being "like ftruncate() but for the middle of the file".
> > So it feels weird to me that MAP_PRIVATE behaves differently; truncate
> > will rip out COWed pages, but holepunch won't.  Is there a good reason for
> > this behaviour, and is it too late to change?
> 
> I see truncate as 'change this global size property of a file' which is
> why we'd rip out COWed pages past the new EOF, whereas punch hole is
> more akin to writing zeroes to a certain file range.  This shouldn't
> affect private mappings that a process has already written to and
> therefore gotten its own copy...

Well, gosh darn it, Darrick!  There you go, having a perfectly good
different mental model from mine which makes just as much sense and
corresponds with the current implementation!

> ...but the manpage says "It is unspecified whether changes made to the
> file after the mmap() call are visible in the mapped region." so I guess
> either way is fine?  Though who knows what now depends on the current
> behavior, so changing it would be hard.

Yeah, I withdraw the question.

> Thinking about this more, it seems weird that if you punch a range
> starting before the cow'd page and ending after the cow'd page that a
> reread of that part of the shared mapping now gets you zeroed pages
> except for the cow'd page which is still intact...?

Well, that's true if I do a write of zeroes to a file which has a
MAP_PRIVATE mapping too.  Face it, MAP_PRIVATE just has odd corner
cases ;-)