From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753375AbdHOQmQ (ORCPT ); Tue, 15 Aug 2017 12:42:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:42934 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752828AbdHOQmO (ORCPT ); Tue, 15 Aug 2017 12:42:14 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E09A22BEA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=jaegeuk@kernel.org Date: Tue, 15 Aug 2017 09:42:12 -0700 From: Jaegeuk Kim To: Chao Yu Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, stable@vger.kernel.org Subject: Re: [PATCH] f2fs: let fill_super handle roll-forward errors Message-ID: <20170815164212.GA4293@jaegeuk-macbookpro.roam.corp.google.com> References: <20170811004204.24078-1-jaegeuk@kernel.org> <20170815032209.GA91145@jaegeuk-macbookpro.roam.corp.google.com> <30b91d0c-63b2-0082-0132-3f188c1a4602@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b91d0c-63b2-0082-0132-3f188c1a4602@huawei.com> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/15, Chao Yu wrote: > On 2017/8/15 11:22, Jaegeuk Kim wrote: > > On 08/15, Chao Yu wrote: > >> Hi Jaegeuk, > >> > >> On 2017/8/11 8:42, Jaegeuk Kim wrote: > >>> If we set CP_ERROR_FLAG in roll-forward error, f2fs is no longer to proceed > >>> any IOs due to f2fs_cp_error(). But, for example, if some stale data is involved > >>> on roll-forward process, we're able to get -ENOENT, getting fs stuck. > >>> If we get any error, let fill_super set SBI_NEED_FSCK and try to recover back > >>> to stable point. > >> > >> Before that, we have cleaned up all node/meta page cache, so we will get back to > >> last checkpoint status, means losing fsynced datas for ever. > >> > >> Would it be better to just leave message reminding user to mount with > >> disable_roll_forward or run fsck offline. > > > > We can't rely on user for this, since fsck cannot recover this, resulting in > > If fsck has no ability to recover this, it could tag superblock in somewhere, > then kernel could skip recovery. Comparing to fail recovery directly, it give > user another chance to rescuer his datas. Huh, what do you mean? This patch let f2fs_fill_super set SBI_NEED_FSCK in superblock and skip roll-forward in second round. > > Thanks, > > > infinite mount failure. The only way is to disable roll-forward recovery, which > > is same as returning error here. > > > > Thanks, > > > >> > >> Thanks, > >> > >>> > >>> Cc: > >>> Signed-off-by: Jaegeuk Kim > >>> --- > >>> fs/f2fs/recovery.c | 2 -- > >>> 1 file changed, 2 deletions(-) > >>> > >>> diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c > >>> index a3d02613934a..f707d810c87d 100644 > >>> --- a/fs/f2fs/recovery.c > >>> +++ b/fs/f2fs/recovery.c > >>> @@ -649,8 +649,6 @@ int recover_fsync_data(struct f2fs_sb_info *sbi, bool check_only) > >>> } > >>> > >>> clear_sbi_flag(sbi, SBI_POR_DOING); > >>> - if (err) > >>> - set_ckpt_flags(sbi, CP_ERROR_FLAG); > >>> mutex_unlock(&sbi->cp_mutex); > >>> > >>> /* let's drop all the directory inodes for clean checkpoint */ > >>> > > > > . > >