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 ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
