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=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 A7D0AC47080 for ; Tue, 1 Jun 2021 10:10:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 82CE2613AE for ; Tue, 1 Jun 2021 10:10:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232968AbhFAKMQ (ORCPT ); Tue, 1 Jun 2021 06:12:16 -0400 Received: from szxga08-in.huawei.com ([45.249.212.255]:3320 "EHLO szxga08-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230282AbhFAKML (ORCPT ); Tue, 1 Jun 2021 06:12:11 -0400 Received: from dggemx753-chm.china.huawei.com (unknown [172.30.72.54]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4FvSTk388Sz1BFwL; Tue, 1 Jun 2021 18:05:46 +0800 (CST) Received: from szvp000207684.huawei.com (10.120.216.130) by dggemx753-chm.china.huawei.com (10.0.44.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 1 Jun 2021 18:10:27 +0800 From: Chao Yu To: CC: , , , Chao Yu Subject: [PATCH v2 RFC] f2fs: fix to force keeping write barrier for strict fsync mode Date: Tue, 1 Jun 2021 18:10:24 +0800 Message-ID: <20210601101024.119356-1-yuchao0@huawei.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.120.216.130] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggemx753-chm.china.huawei.com (10.0.44.37) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [1] https://www.mail-archive.com/linux-f2fs-devel@lists.sourceforge.net/msg15126.html As [1] reported, if lower device doesn't support write barrier, in below case: - write page #0; persist - overwrite page #0 - fsync - write data page #0 OPU into device's cache - write inode page into device's cache - issue flush If SPO is triggered during flush command, inode page can be persisted before data page #0, so that after recovery, inode page can be recovered with new physical block address of data page #0, however there may contains dummy data in new physical block address. Then what user will see is: after overwrite & fsync + SPO, old data in file was corrupted, if any user do care about such case, we can suggest user to use STRICT fsync mode, in this mode, we will force to trigger preflush command to persist data in device cache in prior to node writeback, it avoids potential data corruption during fsync(). Signed-off-by: Chao Yu --- v2: - fix this by adding additional preflush command rather than using atomic write flow. fs/f2fs/file.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 7d5311d54f63..238ca2a733ac 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -301,6 +301,20 @@ static int f2fs_do_sync_file(struct file *file, loff_t start, loff_t end, f2fs_exist_written_data(sbi, ino, UPDATE_INO)) goto flush_out; goto out; + } else { + /* + * for OPU case, during fsync(), node can be persisted before + * data when lower device doesn't support write barrier, result + * in data corruption after SPO. + * So for strict fsync mode, force to trigger preflush to keep + * data/node write order to avoid potential data corruption. + */ + if (F2FS_OPTION(sbi).fsync_mode == FSYNC_MODE_STRICT && + !atomic) { + ret = f2fs_issue_flush(sbi, inode->i_ino); + if (ret) + goto out; + } } go_write: /* -- 2.29.2