From: Chris Mason <chris.mason@fusionio.com>
To: Chris Mason <chris.mason@fusionio.com>,
Alexandre Oliva <oliva@gnu.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Cc: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: corruption of active mmapped files in btrfs snapshots
Date: Fri, 22 Mar 2013 16:31:42 -0400 [thread overview]
Message-ID: <20130322203142.27874.84834@localhost.localdomain> (raw)
In-Reply-To: <20130322180705.27874.96638@localhost.localdomain>
Quoting Chris Mason (2013-03-22 14:07:05)
> [ mmap corruptions with leveldb and btrfs compression ]
>
> I ran this a number of times with compression off and wasn't able to
> trigger problems. With compress=lzo, I see errors on every run.
>
> Compile: gcc -Wall -o mmap-trunc mmap-trunc.c
> Run: ./mmap-trunc file_name
>
> The basic idea is to create a 256MB file in steps. Each step ftruncates
> the file larger, and then mmaps a region for writing. It dirties some
> unaligned bytes (a little more than 8K), and then munmaps.
>
> Then a verify stage goes back through the file to make sure the data we
> wrote is really there. I'm using a simple rotating pattern of chars
> that compress very well.
Going through the code here, when I change the test to truncate once in
the very beginning, I still get errors. So, it isn't an interaction
between mmap and truncate. It must be a problem between lzo and mmap.
-chris
next prev parent reply other threads:[~2013-03-22 20:31 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-18 21:14 corruption of active mmapped files in btrfs snapshots Alexandre Oliva
2013-03-18 21:14 ` Alexandre Oliva
2013-03-18 22:43 ` Alexandre Oliva
2013-03-18 22:52 ` Chris Mason
2013-03-18 22:52 ` Chris Mason
2013-03-19 5:20 ` Alexandre Oliva
2013-03-19 5:20 ` Alexandre Oliva
2013-03-19 12:09 ` Chris Mason
2013-03-19 17:29 ` Sage Weil
2013-03-19 19:26 ` Alexandre Oliva
2013-03-19 19:26 ` Alexandre Oliva
2013-03-19 19:26 ` Alexandre Oliva
2013-03-19 19:26 ` Alexandre Oliva
2013-03-20 1:58 ` Alexandre Oliva
2013-03-20 1:58 ` Alexandre Oliva
2013-03-21 7:14 ` Alexandre Oliva
2013-03-21 7:14 ` Alexandre Oliva
2013-03-21 18:06 ` Chris Mason
2013-03-21 18:06 ` Chris Mason
2013-03-21 23:06 ` Chris Mason
2013-03-21 23:06 ` Chris Mason
2013-03-22 5:27 ` Alexandre Oliva
2013-03-22 5:27 ` Alexandre Oliva
2013-03-22 12:07 ` Chris Mason
2013-03-22 14:17 ` Alexandre Oliva
2013-03-22 14:17 ` Alexandre Oliva
2013-03-22 14:26 ` Chris Mason
2013-03-22 17:06 ` Samuel Just
2013-03-22 17:12 ` Chris Mason
2013-03-23 9:47 ` Alexandre Oliva
2013-03-23 9:47 ` Alexandre Oliva
2013-03-22 17:08 ` David Sterba
2013-03-23 9:48 ` Alexandre Oliva
2013-03-23 9:48 ` Alexandre Oliva
2013-03-25 15:33 ` David Sterba
2013-03-22 17:18 ` Sage Weil
2013-03-22 18:07 ` Chris Mason
2013-03-22 20:31 ` Chris Mason [this message]
2013-03-26 0:08 ` Chris Mason
2013-03-29 9:56 ` Alexandre Oliva
2013-03-29 9:56 ` Alexandre Oliva
2013-03-29 11:35 ` Chris Mason
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=20130322203142.27874.84834@localhost.localdomain \
--to=chris.mason@fusionio.com \
--cc=ceph-devel@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=oliva@gnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.