:
:Matthew Dillon wrote:
:> The small-temporary-file trick is simple: create a small temporary
:> file, get a file descriptor to it, remove() the file, then ftruncate()
:> the descriptor to the amount of space you need, mmap() it
:> MAP_PRIVATE, and close the descriptor. Since it is a private map no
:> actual space is allocated for the file, only an inode. You can
:> leave the descriptor open if you need to 'allocate' more space using
:> additional calls to mmap().
:
:One of his original issues was avoiding overcommit. In the file
:backed region case, as I suggested in my original response, to
:get this behaviour, he would have to touch each of the blocks in
:the file following the truncation, to make sure he didn't fall
:into an overcommit based failure later.
:
:-- Terry
This example was for anonymous memory, not file-backed memory.
mmap()ing the dummy file MAP_PRIVATE means that none of the I/O
ever gets to the filesystem or the file, so no blocks are ever
allocated (or ever have to be).
The only responsible, reasonable, and dependable way to avoid
overcommit is to outfit the system according to the type of
load you want to place on it, and for the programs being run
to be told how far they are allowed to go and to govern
themselves using that information. This is going to be true
whether you are backing your storage with anonymous memory
(swap/phys backed), or whether you are backing it with a
pre-written file.
Simply using a pre-written file does not really guarentee
anything... after all, you can run out of space on the
filesystem as easily as you can run out of VM, and if you
store other things, like configuration data, in the same
filesystem, you are just as vulnerable to bad programming
in the event of a write() filesystem-full failure as you
are vulnerable to overcomitting the VM system to the point
where it starts killing processes.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
