From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com ([66.111.4.28]:57475 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728530AbeKSWxs (ORCPT ); Mon, 19 Nov 2018 17:53:48 -0500 Date: Mon, 19 Nov 2018 13:30:16 +0100 From: Greg KH To: Qu Wenruo Cc: stable@vger.kernel.org, David Sterba Subject: Re: [PATCH 1/2] btrfs: Enhance btrfs_trim_fs function to handle error better Message-ID: <20181119123016.GA18911@kroah.com> References: <20181112003242.17674-1-wqu@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181112003242.17674-1-wqu@suse.com> Sender: stable-owner@vger.kernel.org List-ID: On Mon, Nov 12, 2018 at 08:32:41AM +0800, Qu Wenruo wrote: > Commit 93bba24d4b5ad1e5cd8b43f64e66ff9d6355dd20 upstream. > > Function btrfs_trim_fs() doesn't handle errors in a consistent way. If > error happens when trimming existing block groups, it will skip the > remaining blocks and continue to trim unallocated space for each device. > > The return value will only reflect the final error from device trimming. > > This patch will fix such behavior by: > > 1) Recording the last error from block group or device trimming > The return value will also reflect the last error during trimming. > Make developer more aware of the problem. > > 2) Continuing trimming if possible > If we failed to trim one block group or device, we could still try > the next block group or device. > > 3) Report number of failures during block group and device trimming > It would be less noisy, but still gives user a brief summary of > what's going wrong. > > Such behavior can avoid confusion for cases like failure to trim the > first block group and then only unallocated space is trimmed. > > Reported-by: Chris Murphy > CC: stable@vger.kernel.org # 4.9 > Signed-off-by: Qu Wenruo > Reviewed-by: David Sterba > [ add bg_ret and dev_ret to the messages ] > Signed-off-by: David Sterba > --- > fs/btrfs/extent-tree.c | 40 +++++++++++++++++++++++++++++----------- > 1 file changed, 29 insertions(+), 11 deletions(-) Does not apply to the latest 4.9.y tree :( Can you please rebase and resend both of these? thanks, greg k-h