From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: corruption of active mmapped files in btrfs snapshots Date: Fri, 22 Mar 2013 16:31:42 -0400 Message-ID: <20130322203142.27874.84834@localhost.localdomain> References: <20130322180705.27874.96638@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Return-path: Received: from dkim1.fusionio.com ([66.114.96.53]:57728 "EHLO dkim1.fusionio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422904Ab3CVUbp convert rfc822-to-8bit (ORCPT ); Fri, 22 Mar 2013 16:31:45 -0400 Received: from mx1.fusionio.com (unknown [10.101.1.160]) by dkim1.fusionio.com (Postfix) with ESMTP id 8B5F17C04F9 for ; Fri, 22 Mar 2013 14:31:44 -0600 (MDT) In-Reply-To: <20130322180705.27874.96638@localhost.localdomain> Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Chris Mason , Alexandre Oliva , "linux-btrfs@vger.kernel.org" Cc: "ceph-devel@vger.kernel.org" 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