From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCEC8C04EB8 for ; Fri, 30 Nov 2018 20:28:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 84FE52145D for ; Fri, 30 Nov 2018 20:28:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="l+La15s3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 84FE52145D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726996AbeLAHih (ORCPT ); Sat, 1 Dec 2018 02:38:37 -0500 Received: from mail.kernel.org ([198.145.29.99]:53646 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726889AbeLAHih (ORCPT ); Sat, 1 Dec 2018 02:38:37 -0500 Received: from localhost (unknown [104.132.1.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 661AA20868; Fri, 30 Nov 2018 20:28:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1543609688; bh=MJvqbUjASp/0j00m7EYlzJUsQT73KgXQDK/SqRq0l78=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=l+La15s3JhrZTkDa1/q6sA+KVfDFi7yfEyk38kZ5wU+MIrGxUnTKw6MYkl6kakBRD v6HFS1SmlUfvSQJ2F0yQu6iEW7G1mECx7Pfxtk5UomcCPba172YVRKb/fFI35ZuZ0V meynT8Zx5j4UncdXPN02sq0yczRQdOJd3p+YCz4k= Date: Fri, 30 Nov 2018 12:28:07 -0800 From: Jaegeuk Kim To: Chao Yu Cc: Sheng Yong , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [f2fs-dev] [PATCH] f2fs: avoid frequent costly fsck triggers Message-ID: <20181130202807.GA71781@jaegeuk-macbookpro.roam.corp.google.com> References: <20181128073125.39102-1-jaegeuk@kernel.org> <724de929-6ee1-3ad7-cfa7-6e80d4e7a3da@huawei.com> <20181128081035.GA41969@jaegeuk-macbookpro.roam.corp.google.com> <4f43735a-d01f-f194-18ce-4fbbe10ad8d4@huawei.com> <20181128174805.GB41969@jaegeuk-macbookpro.roam.corp.google.com> <234cabcd-a1c1-9fb6-13aa-94fe681731dc@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/30, Chao Yu wrote: > On 2018/11/30 10:35, Sheng Yong wrote: > > Hi, Jaegeuk and Chao, > > > > On 2018/11/29 1:48, Jaegeuk Kim wrote: > >> On 11/28, Chao Yu wrote: > >>> On 2018/11/28 16:10, Jaegeuk Kim wrote: > >>>> On 11/28, Chao Yu wrote: > >>>>> Hi Jaeguek, > >>>>> > >>>>> On 2018/11/28 15:31, Jaegeuk Kim wrote: > >>>>>> If we want to re-enable nat_bits, we rely on fsck which requires full scan > >>>>>> of directory tree. Let's do that by regular fsck or unclean shutdown. > >>>>> > >>>>> Reviewed-by: Chao Yu > >>>>> > >>>>> BTW, I have patch made some month ago... > >>>>> > >>>>> In order to detect nat_bits disabling, could we introduce one more flag for > >>>>> fsck? > >>>> > >>>> Do we have a way to enable nat_bits very quickly in fsck? > >>> > >>> For image with SBI_NATBIT_NEED_REPAIR flag, can we just check metadata and > >>> rebuild nat_bits based on verified nat blocks/journals? > >> > >> I'm leaning to rely on full scan to enable nat_bits again. We may add a mount > >> count or timer to trigger fsck regularly? > > > > I'm afraid regular full fsck would give us bad experience of booting time. > > FYI, 256GB storage, which is filled with small files, costs almost 10 min > > to do a full fsck. And it seems larger capacity storages are on the way. > > Agreed. Agreed. So, that's why I wrote this patch. > > > So, is it worth doing that only to enable nat_bits (plus checking f2fs > > consistent not that necessarily)? > > In android environment, I think it may be too expensive for adding nat_bits > by triggering full scan by fsck during boot time. That's why I'd like to enable this only when we need full scan. > > If we can update all nat bitmap in free time after mount, maybe we can > rebuild nat_bits based on full nat bitmap during umount, which can be > cheaper than rebuiding in userspace. Yeah, rebuiling nat_bits in run time would be better, but can be applied in future. But, since Android reboot procedure uses a timeout, if we exceed it, we'll get unclean unmount which triggers another fsck, which doesn't make sense at all. > > Thanks, > > > > > Thanks > >> > >>> > >>> Thanks, > >>> > >>>> > >>>>> > >>>>> >From 86e8bdb2faeec904944bb6621073f4f7de51cc2d Mon Sep 17 00:00:00 2001 > >>>>> From: Chao Yu > >>>>> Date: Sun, 9 Sep 2018 05:40:20 +0800 > >>>>> Subject: [PATCH] f2fs: set specified flag after invalidating nat_bits > >>>>> > >>>>> Signed-off-by: Chao Yu > >>>>> --- > >>>>> fs/f2fs/checkpoint.c | 12 +++++++++++- > >>>>> fs/f2fs/f2fs.h | 3 ++- > >>>>> fs/f2fs/node.c | 3 +++ > >>>>> include/linux/f2fs_fs.h | 1 + > >>>>> 4 files changed, 17 insertions(+), 2 deletions(-) > >>>>> > >>>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > >>>>> index 7e17bb3dfcb1..f7fb14e0f5f9 100644 > >>>>> --- a/fs/f2fs/checkpoint.c > >>>>> +++ b/fs/f2fs/checkpoint.c > >>>>> @@ -1226,13 +1226,16 @@ static void update_ckpt_flags(struct f2fs_sb_info > >>>>> *sbi, struct cp_control *cpc) > >>>>> unsigned long orphan_num = sbi->im[ORPHAN_INO].ino_num; > >>>>> struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi); > >>>>> unsigned long flags; > >>>>> + bool disable_natbits = false; > >>>>> > >>>>> spin_lock_irqsave(&sbi->cp_lock, flags); > >>>>> > >>>>> if ((cpc->reason & CP_UMOUNT) && > >>>>> le32_to_cpu(ckpt->cp_pack_total_block_count) > > >>>>> - sbi->blocks_per_seg - NM_I(sbi)->nat_bits_blocks) > >>>>> + sbi->blocks_per_seg - NM_I(sbi)->nat_bits_blocks) { > >>>>> disable_nat_bits(sbi, false); > >>>>> + disable_natbits = true; > >>>>> + } > >>>>> > >>>>> if (cpc->reason & CP_TRIMMED) > >>>>> __set_ckpt_flags(ckpt, CP_TRIMMED_FLAG); > >>>>> @@ -1270,11 +1273,18 @@ static void update_ckpt_flags(struct f2fs_sb_info > >>>>> *sbi, struct cp_control *cpc) > >>>>> if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) > >>>>> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > >>>>> > >>>>> + if (is_sbi_flag_set(sbi, SBI_NATBIT_NEED_REPAIR)) > >>>>> + __set_ckpt_flags(ckpt, CP_NATBIT_NEED_FSCK_FLAG); > >>>>> + > >>>>> /* set this flag to activate crc|cp_ver for recovery */ > >>>>> __set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG); > >>>>> __clear_ckpt_flags(ckpt, CP_NOCRC_RECOVERY_FLAG); > >>>>> > >>>>> spin_unlock_irqrestore(&sbi->cp_lock, flags); > >>>>> + > >>>>> + if (disable_natbits) > >>>>> + f2fs_msg(sbi->sb, KERN_NOTICE, > >>>>> + "No enough space in CP area, disable nat_bits."); > >>>>> } > >>>>> > >>>>> static void commit_checkpoint(struct f2fs_sb_info *sbi, > >>>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h > >>>>> index f0cedbe0c536..b55341c269b2 100644 > >>>>> --- a/fs/f2fs/f2fs.h > >>>>> +++ b/fs/f2fs/f2fs.h > >>>>> @@ -1107,6 +1107,7 @@ enum { > >>>>> SBI_QUOTA_NEED_FLUSH, /* need to flush quota info in CP */ > >>>>> SBI_QUOTA_SKIP_FLUSH, /* skip flushing quota in current CP */ > >>>>> SBI_QUOTA_NEED_REPAIR, /* quota file may be corrupted */ > >>>>> + SBI_NATBIT_NEED_REPAIR, /* nat full/empty bitmaps need repair */ > >>>>> }; > >>>>> > >>>>> enum { > >>>>> @@ -1628,7 +1629,7 @@ static inline void disable_nat_bits(struct > >>>>> f2fs_sb_info *sbi, bool lock) > >>>>> { > >>>>> unsigned long flags; > >>>>> > >>>>> - set_sbi_flag(sbi, SBI_NEED_FSCK); > >>>>> + set_sbi_flag(sbi, SBI_NATBIT_NEED_REPAIR); > >>>>> > >>>>> if (lock) > >>>>> spin_lock_irqsave(&sbi->cp_lock, flags); > >>>>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c > >>>>> index e57add1e8966..0c6f8312a087 100644 > >>>>> --- a/fs/f2fs/node.c > >>>>> +++ b/fs/f2fs/node.c > >>>>> @@ -2902,6 +2902,9 @@ static int __get_nat_bitmaps(struct f2fs_sb_info *sbi) > >>>>> > >>>>> cp_ver |= (cur_cp_crc(ckpt) << 32); > >>>>> if (cpu_to_le64(cp_ver) != *(__le64 *)nm_i->nat_bits) { > >>>>> + f2fs_msg(sbi->sb, KERN_NOTICE, > >>>>> + "Disable nat_bits due to incorrect cp_ver (%llu, %llu)", > >>>>> + cp_ver, le64_to_cpu(*(__le64 *)nm_i->nat_bits)); > >>>>> disable_nat_bits(sbi, true); > >>>>> return 0; > >>>>> } > >>>>> diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h > >>>>> index 7196653833fa..1f3ae1504573 100644 > >>>>> --- a/include/linux/f2fs_fs.h > >>>>> +++ b/include/linux/f2fs_fs.h > >>>>> @@ -117,6 +117,7 @@ struct f2fs_super_block { > >>>>> /* > >>>>> * For checkpoint > >>>>> */ > >>>>> +#define CP_NATBIT_NEED_FSCK_FLAG 0X00002000 > >>>>> #define CP_DISABLED_FLAG 0x00001000 > >>>>> #define CP_QUOTA_NEED_FSCK_FLAG 0x00000800 > >>>>> #define CP_LARGE_NAT_BITMAP_FLAG 0x00000400 > >>>>> -- > >>>>> 2.18.0.rc1 > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> Signed-off-by: Jaegeuk Kim > >>>>>> --- > >>>>>> fs/f2fs/f2fs.h | 6 +++++- > >>>>>> 1 file changed, 5 insertions(+), 1 deletion(-) > >>>>>> > >>>>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h > >>>>>> index c28a9d1cb278..aa500239baf2 100644 > >>>>>> --- a/fs/f2fs/f2fs.h > >>>>>> +++ b/fs/f2fs/f2fs.h > >>>>>> @@ -1621,7 +1621,11 @@ static inline void disable_nat_bits(struct f2fs_sb_info *sbi, bool lock) > >>>>>> { > >>>>>> unsigned long flags; > >>>>>> > >>>>>> - set_sbi_flag(sbi, SBI_NEED_FSCK); > >>>>>> + /* > >>>>>> + * In order to re-enable nat_bits we need to call fsck.f2fs by > >>>>>> + * set_sbi_flag(sbi, SBI_NEED_FSCK). But it may give huge cost, > >>>>>> + * so let's rely on regular fsck or unclean shutdown. > >>>>>> + */ > >>>>>> > >>>>>> if (lock) > >>>>>> spin_lock_irqsave(&sbi->cp_lock, flags); > >>>>>> > >>>> > >>>> . > >>>> > >> > >> > >> _______________________________________________ > >> Linux-f2fs-devel mailing list > >> Linux-f2fs-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > >> > >> . > >> > > > > > > . > >