linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Eugene V. Lyubimkin" <jackyf.devel@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm <linux-mm@kvack.org>,
	hugh <hugh@veritas.com>, riel <riel@redhat.com>
Subject: Re: mmap: is default non-populating behavior stable?
Date: Mon, 03 Nov 2008 23:41:23 +0100	[thread overview]
Message-ID: <1225752083.7803.1644.camel@twins> (raw)
In-Reply-To: <490F73CD.4010705@gmail.com>

On Mon, 2008-11-03 at 23:57 +0200, Eugene V. Lyubimkin wrote:
> Hello kernel hackers!
> 
> The current implementation of mmap() in kernel is very convenient.
> It allows to mmap(fd) very big amount of memory having small file as back-end.
> So one can mmap() 100 MiB on empty file, use first 10 KiB of memory, munmap() and have
> only 10 KiB of file at the end. And while working with memory, file will automatically be
> grown by read/write memory requests.
> 
> Question is: can user-space application rely on this behavior (I failed to find any
> documentation about this)?
> 
> TIA and please CC me in replies.

mmap() writes past the end of the file should not grow the file if I
understand things write, but produce a sigbus (after the first page size
alignment).

The exact interaction of mmap() and truncate() I'm not exactly clear on.

The safe way to do things is to first create your file of at least the
size you mmap, using truncate. This will create a sparse file, and will
on any sane filesystem not take more space than its meta data.

Thereafter you can fill it with writes to the mmap.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

       reply	other threads:[~2008-11-03 22:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <490F73CD.4010705@gmail.com>
2008-11-03 22:41 ` Peter Zijlstra [this message]
2008-11-03 22:49   ` Rik van Riel
2008-11-04 15:56     ` Chris Friesen
2008-11-04 16:07       ` Peter Zijlstra
2008-11-04 16:28         ` Alan Cox
2008-11-04 16:51           ` Eugene V. Lyubimkin
2008-11-05 16:42             ` Hugh Dickins
2008-11-05 16:54               ` Alan Cox
2008-11-05 17:50               ` Eugene V. Lyubimkin
2008-11-05 23:31                 ` Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1225752083.7803.1644.camel@twins \
    --to=peterz@infradead.org \
    --cc=hugh@veritas.com \
    --cc=jackyf.devel@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox