Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp958534pxy; Wed, 5 May 2021 19:16:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwB4N+qHtBxvpMKDy6q5fV+2qt/EMhpKOZUXMUHQm63bmtuJPltEUYPqrawUlzAoz8BDTzX X-Received: by 2002:a17:906:8414:: with SMTP id n20mr1819333ejx.524.1620267402444; Wed, 05 May 2021 19:16:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620267402; cv=none; d=google.com; s=arc-20160816; b=FaUpqL2SHIBEbjeqlWwuMqeCjW5oCBlhS5Ra2i0tmY1KjP70iq3+mKy8bDm+iN+UvN 8KrPsEiGLZAcLZJNoITuTzOSXi10aaICe305bf17Kw3vTPRDUmGJs8AwkDlSamiOGmzE rsgkfbw5kWda/Z1NxsLxXKsHs6PWsOXmh/o2A3oa+kJMCCuFmXtDCNG5mKVHPOWGNDJ9 HKzLf+a+HdBDDUvrPkLVseIK/aR29+o08sI7WiRl00vIVytoG6ciW4NPT1b5/SEccidT x31AoMQmFXU/lq7hStgmvSg8crQYO/67VhQu1N2SnD3iihVCZWqwEcZDWXUa4FknjA1Z vXow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=dwLGArLuZQ1aiBD6GIrSf6nnE4Mqb4Ojinaz59KnLgI=; b=cJQE7/xdQO856GcNSZMqvgOswQSVGOdSAcoQpcoK8pBzEu2BnePPxCrYT4TeiRM1qw NRt/VRTNYQIM5qjvkM35DgZ8+8rYhdVSddxYhqkgt6lxzJFsIGf10TzdNtMa2LfNe4ag OLaIUVZ4nLttHaRCR8SyvSHPE8BWUGJmucugX3jsGa1aF4G2PMukM7sayFkaQOMdp6HZ PWzLlL3v6oCeqdjyZHwveaFmY0X2GJI+ZEt7KyEPQ3UJCvcApn4GlrQvyfmcnJ4QZrmQ MUMBpCS337uCFmWkn841RqoyovwSGPLuvjeJIO0istONmBag73Sqnccq3yapq76L+t4x F/dg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sd1si952248ejb.90.2021.05.05.19.16.19; Wed, 05 May 2021 19:16:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229889AbhEFCQX (ORCPT + 99 others); Wed, 5 May 2021 22:16:23 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:18001 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229465AbhEFCQW (ORCPT ); Wed, 5 May 2021 22:16:22 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4FbHCC0wXmzPwTm; Thu, 6 May 2021 10:12:07 +0800 (CST) Received: from [10.136.110.154] (10.136.110.154) by smtp.huawei.com (10.3.19.206) with Microsoft SMTP Server (TLS) id 14.3.498.0; Thu, 6 May 2021 10:15:20 +0800 Subject: Re: [PATCH v2] f2fs: reduce expensive checkpoint trigger frequency To: Jaegeuk Kim CC: , , , Yunlei He References: <20210425011053.44436-1-yuchao0@huawei.com> <3338f2bc-6985-c1a4-9f3d-e59a474027f9@huawei.com> From: Chao Yu Message-ID: <912459e6-3eef-59b7-e8a3-1097efd22750@huawei.com> Date: Thu, 6 May 2021 10:15:19 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.136.110.154] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/5/4 22:36, Jaegeuk Kim wrote: > On 04/27, Chao Yu wrote: >> On 2021/4/27 1:09, Jaegeuk Kim wrote: >>> On 04/25, Chao Yu wrote: >>>> We may trigger high frequent checkpoint for below case: >>>> 1. mkdir /mnt/dir1; set dir1 encrypted >>>> 2. touch /mnt/file1; fsync /mnt/file1 >>>> 3. mkdir /mnt/dir2; set dir2 encrypted >>>> 4. touch /mnt/file2; fsync /mnt/file2 >>>> ... >>>> >>>> Although, newly created dir and file are not related, due to >>>> commit bbf156f7afa7 ("f2fs: fix lost xattrs of directories"), we will >>>> trigger checkpoint whenever fsync() comes after a new encrypted dir >>>> created. >>>> >>>> In order to avoid such condition, let's record an entry including >>>> directory's ino into global cache when we initialize encryption policy >>>> in a checkpointed directory, and then only trigger checkpoint() when >>>> target file's parent has non-persisted encryption policy, for the case >>>> its parent is not checkpointed, need_do_checkpoint() has cover that >>>> by verifying it with f2fs_is_checkpointed_node(). >>>> >>>> Reported-by: Yunlei He >>>> Signed-off-by: Chao Yu >>>> --- >>>> v2: >>>> - fix to set ENC_DIR_INO only for encrypted directory >>>> fs/f2fs/f2fs.h | 2 ++ >>>> fs/f2fs/file.c | 3 +++ >>>> fs/f2fs/xattr.c | 6 ++++-- >>>> include/trace/events/f2fs.h | 3 ++- >>>> 4 files changed, 11 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h >>>> index b9d5317db0a7..0fe881309a20 100644 >>>> --- a/fs/f2fs/f2fs.h >>>> +++ b/fs/f2fs/f2fs.h >>>> @@ -246,6 +246,7 @@ enum { >>>> APPEND_INO, /* for append ino list */ >>>> UPDATE_INO, /* for update ino list */ >>>> TRANS_DIR_INO, /* for trasactions dir ino list */ >>>> + ENC_DIR_INO, /* for encrypted dir ino list */ >>>> FLUSH_INO, /* for multiple device flushing */ >>>> MAX_INO_ENTRY, /* max. list */ >>>> }; >>>> @@ -1090,6 +1091,7 @@ enum cp_reason_type { >>>> CP_FASTBOOT_MODE, >>>> CP_SPEC_LOG_NUM, >>>> CP_RECOVER_DIR, >>>> + CP_ENC_DIR, >>>> }; >>>> enum iostat_type { >>>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c >>>> index a595050c56d3..62af29ec0879 100644 >>>> --- a/fs/f2fs/file.c >>>> +++ b/fs/f2fs/file.c >>>> @@ -218,6 +218,9 @@ static inline enum cp_reason_type need_do_checkpoint(struct inode *inode) >>>> f2fs_exist_written_data(sbi, F2FS_I(inode)->i_pino, >>>> TRANS_DIR_INO)) >>>> cp_reason = CP_RECOVER_DIR; >>>> + else if (f2fs_exist_written_data(sbi, F2FS_I(inode)->i_pino, >>>> + ENC_DIR_INO)) >>>> + cp_reason = CP_ENC_DIR; >>>> return cp_reason; >>>> } >>>> diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c >>>> index c8f34decbf8e..70615d504f7e 100644 >>>> --- a/fs/f2fs/xattr.c >>>> +++ b/fs/f2fs/xattr.c >>>> @@ -630,6 +630,7 @@ static int __f2fs_setxattr(struct inode *inode, int index, >>>> const char *name, const void *value, size_t size, >>>> struct page *ipage, int flags) >>>> { >>>> + struct f2fs_sb_info *sbi = F2FS_I_SB(inode); >>>> struct f2fs_xattr_entry *here, *last; >>>> void *base_addr, *last_base_addr; >>>> int found, newsize; >>>> @@ -745,8 +746,9 @@ static int __f2fs_setxattr(struct inode *inode, int index, >>>> !strcmp(name, F2FS_XATTR_NAME_ENCRYPTION_CONTEXT)) >>>> f2fs_set_encrypted_inode(inode); >>>> f2fs_mark_inode_dirty_sync(inode, true); >>>> - if (!error && S_ISDIR(inode->i_mode)) >>>> - set_sbi_flag(F2FS_I_SB(inode), SBI_NEED_CP); >>>> + if (!error && S_ISDIR(inode->i_mode) && f2fs_encrypted_file(inode) && >>>> + f2fs_is_checkpointed_node(sbi, inode->i_ino)) >>>> + f2fs_add_ino_entry(sbi, inode->i_ino, ENC_DIR_INO); >>> >>> What will happen, if we need to checkpoint xattr_nid on this directory? >> >> need_do_checkpoint() >> >> a) else if (!f2fs_is_checkpointed_node(sbi, F2FS_I(inode)->i_pino)) >> cp_reason = CP_NODE_NEED_CP; > > This will change the current behavior which does checkpoint regardless of the > parent being checkpointed. If i_pino was checkpointed but xnid wasn't, can we > get xnid being checkpointed? Yes, >> If parent is checkpointed, after converting parent to encrypted directory >> and create the file in parent, fsync this file will trigger checkpoint() due >> to b) If i_pino was checkpointed, but xnid wasn't due to enable encryption on this directory, fsync() this file will trigger checkpoint() to make sure xnid checkpointed due to b) case. Thanks, > >> >> b) else if (f2fs_exist_written_data(sbi, F2FS_I(inode)->i_pino, >> ENC_DIR_INO)) >> cp_reason = CP_ENC_DIR; >> >> If parent is not checkpointed, after converting parent to encrypted directory >> and create the file in parent, fsync this file will trigger checkpoint() due >> to a) >> >> If parent is checkpointed, after converting parent to encrypted directory >> and create the file in parent, fsync this file will trigger checkpoint() due >> to b) >> >> Am I missing any cases? >> >> Thanks, >> >>> >>>> same: >>>> if (is_inode_flag_set(inode, FI_ACL_MODE)) { >>>> diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h >>>> index 56b113e3cd6a..ca0cf12226e9 100644 >>>> --- a/include/trace/events/f2fs.h >>>> +++ b/include/trace/events/f2fs.h >>>> @@ -145,7 +145,8 @@ TRACE_DEFINE_ENUM(CP_RESIZE); >>>> { CP_NODE_NEED_CP, "node needs cp" }, \ >>>> { CP_FASTBOOT_MODE, "fastboot mode" }, \ >>>> { CP_SPEC_LOG_NUM, "log type is 2" }, \ >>>> - { CP_RECOVER_DIR, "dir needs recovery" }) >>>> + { CP_RECOVER_DIR, "dir needs recovery" }, \ >>>> + { CP_ENC_DIR, "persist encryption policy" }) >>>> #define show_shutdown_mode(type) \ >>>> __print_symbolic(type, \ >>>> -- >>>> 2.29.2 >>> . >>> > . >