Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates
 18.9.28.11 as permitted sender) receiver=protection.outlook.com;
 client-ip=18.9.28.11; helo=outgoing.mit.edu;
Date:   Fri, 1 Mar 2019 00:00:09 -0500
From:   "Theodore Y. Ts'o" <tytso@mit.edu>
To:     Eric Whitney <enwlinux@gmail.com>
CC:     <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: fix bigalloc cluster freeing when hole punching
 under load
Message-ID: <20190301050009.GA8234@mit.edu>
References: <20190227220204.31804-1-enwlinux@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190227220204.31804-1-enwlinux@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2019 05:00:11.7400
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ab576506-5bf6-4957-6485-08d69e02c91b
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b;Ip=[18.9.28.11];Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB4854
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-ext4.vger.kernel.org>
X-Mailing-List: linux-ext4@vger.kernel.org

On Wed, Feb 27, 2019 at 05:02:04PM -0500, Eric Whitney wrote:
> Ext4 may not free clusters correctly when punching holes in bigalloc
> file systems under high load conditions.  If it's not possible to
> extend and restart the journal in ext4_ext_rm_leaf() when preparing to
> remove blocks from a punched region, a retry of the entire punch
> operation is triggered in ext4_ext_remove_space().  This causes a
> partial cluster to be set to the first cluster in the extent found to
> the right of the punched region.  However, if the punch operation
> prior to the retry had made enough progress to delete one or more
> extents and a partial cluster candidate for freeing had already been
> recorded, the retry would overwrite the partial cluster.  The loss of
> this information makes it impossible to correctly free the original
> partial cluster in all cases.
> 
> This bug can cause generic/476 to fail when run as part of
> xfstests-bld's bigalloc and bigalloc_1k test cases.  The failure is
> reported when e2fsck detects bad iblocks counts greater than expected
> in units of whole clusters and also detects a number of negative block
> bitmap differences equal to the iblocks discrepancy in cluster units.
> 
> Signed-off-by: Eric Whitney <enwlinux@gmail.com>

Thanks, applied.

							- Ted