creating file space via mmap

[Guy Harris]

>I've been working with mmap to create file space.  There are some problems
>in letting mmap set the size of the file.

Yup, "mmap" doesn't set the size of the file.

>Experimentally, the following DOES work:

As should anything else that grows the file.

>This DOES work; the question is:  can one DEPEND on it working?

Yes.  Not having a pagein of a page backed by a hole work in the proper
UNIX fashion (which would be to zero the page out) would have been a Very
Bad Idea, so it works.  Similarly, modifying that page causes a pageout to
work, by filling in the hole.  (Besides, since "read" and "write" on UFS
and NFS file systems work, in effect, by an in-the-kernel fast path
through "mmap", it might well have broken "read" and "write" were it not
to work.)

>Is there a better way?

Well, it depends on your definition of "better", but:

Users who pored over the 4.0 TRUNCATE(2) man page with a fine-toothed
comb would have noticed that it says

   DESCRIPTION
	truncate() causes the file  referred  to  by  path  (or  for
	ftruncate()  the  object  referred  to by fd) to have a size
	equal to length bytes.  If the file  was  previously  longer
	than  length, the extra bytes are removed from the file.  If
								  ^^
	it was shorter, bytes between the old and  new  lengths  are
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	read  as  zeroes.  With ftruncate, the file must be open for
	^^^^^^^^^^^^^^^^
	writing.

The pre-4.0 TRUNCATE(2), and the 4.xBSD ones, didn't say anything about
"(f)truncate" making files larger.  The reason why "(f)truncate" was,
extended to allow you to, err, umm, *extend* the file (no pun intended)
was to let you grow a file to which you were writing via "mmap" rather
than via "write". 

I don't know if this was mentioned in the Read (Me|This) First (one is
for software, one is for hardware, I can't remember which is which), so
it may have been somewhat obscure....