From: Petr Tesarik <ptesarik@suse.cz>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: mmap behavior on out-of-space conditions
Date: Thu, 02 Aug 2007 14:41:26 +0200 [thread overview]
Message-ID: <1186058486.2289.17.camel@elijah.suse.cz> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2047 bytes --]
Hello,
while solving a different issue, my colleague Libor Pechacek found a
problem with handling mmapped sparse files. If you mmap the hole insidea
sparse file and write to it, the data gets silently lost if there is not
enough space left on the underlying device.
I found a thread which touched this topic in December 2001 (sic!). I'd
like to quote an email by Andrea Arcangeli:
> On Sun, Dec 30, 2001 at 01:33:24AM -0500, Alexander Viro wrote:
> >
> >
> > On Sat, 29 Dec 2001, Andrew Morton wrote:
> >
> > > Would it be necessary to preallocate the holes at mmap() time? Mad
> > > hand-waving: Could we not perform the instantiation at pagefault time,
> > > and give the caller SIGBUS if we cannot allocate the blocks? Or if
> > > there's an IO error, or quota exceeded.
> >
> > Allocation at mmap() Is Not Going To Happen. Consider it vetoed.
> > There are applications that use mmap() on large and very sparse
> > files.
>
> it's exactly this kind of apps that will be screwed up by silent data
> corruption. the point of the holes is to optimize performance and save
> space, but they shouldn't introduce the possibilty of data corruption.
>
> Note: I'm fine to introduce another way to notify the app about -ENOSPC,
> -ENOSPC on mmap is the most obvious one, but we could still allow the
> current "overcommit" behaviour with a kind of sigbus mentioned by
> Andrew (possibly not sigbus though, since it has just well defined
> semantics for MAP_SHARED, maybe they could be extended, anyways as said
> this is only a matter of API). My point is only that some API should be
> added because your mmap on sparse files are unreliable at the moment.
(see http://marc.info/?l=linux-kernel&m=100975730421590&w=2)
However, this is still not fixed - I am attaching a simple test case,
run it like:
$ make
$ # become root
# make check
IMO we should go with the SIGBUS solution, but I want to discuss it here
before making a patch.
Kind regards,
Petr Tesarik
SUSE LINUX, L3 Prague
[-- Attachment #1.2: mmap-nospc.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 1242 bytes --]
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2007-08-02 12:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-02 12:41 Petr Tesarik [this message]
2007-08-02 13:06 ` Peter Zijlstra
2007-08-02 13:18 ` Guillaume Chazarain
2007-08-02 18:52 ` Andrew Morton
2007-08-02 22:20 ` David Chinner
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=1186058486.2289.17.camel@elijah.suse.cz \
--to=ptesarik@suse.cz \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®