Can one of the admins verify this patch?

test this please

retest this please

I'm not sure how much optimisation that code needs (though I am in favour of posix_fallocate() part, thank you) as it's only called at rb_open() time.

I'm not sure how much optimisation that code needs (though I am in favour of posix_fallocate() part, thank you) as it's only called at rb_open() time.

Ok, so we shouldn't bother with optimizing memset as something interesting.

Continuing to think about this: As far as I can see now, even doing write after posix_fallocate shouldn't be needed to get the newly allocated blocks be read as zeros. Several sources coincide on saying they will be read as zeros:

• some tests recently run by @wladmis
• an argument given at stackoverflow:

The original question says something about writing zeros to the file. None of these calls write anything but metadata. If you read from space that's been preallocated but not yet written, you'll get zeros (not whatever was in that disk space previously, that would be a big security hole). You can only read up to the end of a file (the length, set by fallocate, ftruncate, or various other ways)

• NetBSD's manpage:

When posix_fallocate() is applied to an unallocated region in a regular file (a ``hole''), the hole is filled and the visible contents are unaffected; both holes and newly allocated regions read as all zeros.

The old existing blocks in the file remain unzeroed, though. If we consider qb_sys_mmap_file_open in isolation, can this mean that this patch changes its intended behavior in non-equivalent manner?.. (I.e., posix_fallocate not zeroing the initial bytes.) No, because it is used from qb_rb_open in rungbuffer.c; there the flags are set simultanously:

	if (flags & QB_RB_FLAG_CREATE) {
		file_flags |= O_CREAT | O_TRUNC;
	}

So, the zeroing used to happen when O_CREAT is set, and O_TRUNC is set then always, too. So, first, the file is truncated to zero length, and only then extended by the new blocks.

The old existing blocks in the file remain unzeroed, though. If we consider qb_sys_mmap_file_open in isolation, can this mean that this patch changes its intended behavior in non-equivalent manner?.. (I.e., posix_fallocate not zeroing the initial bytes.) No, because it is used from qb_rb_open in rungbuffer.c; there the flags are set simultanously:

	if (flags & QB_RB_FLAG_CREATE) {
		file_flags |= O_CREAT | O_TRUNC;
	}

So, the zeroing used to happen when O_CREAT is set, and O_TRUNC is set then always, too. So, first, the file is truncated to zero length, and only then extended by the new blocks.

The only other uses of this function are from ipc_us.c, and there, too, O_CREAT (when zeroing happens) and O_TRUNC got always together:

	fd_hdr = qb_sys_mmap_file_open(path, r->request,
				       SHM_CONTROL_SIZE, O_RDWR);

or

	fd_hdr = qb_sys_mmap_file_open(path, r->request,
				       SHM_CONTROL_SIZE,
				       O_CREAT | O_TRUNC | O_RDWR);

retest this please

Merged. Thanks very much!