Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3345093pxj; Tue, 1 Jun 2021 03:12:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzlWO+apN96RyVD5uJWeJod7eup3TLhIcutz+WUgyIB8VEK7MRSUwckTx2Z+fQxtPHmncia X-Received: by 2002:a50:ee18:: with SMTP id g24mr2364523eds.11.1622542346980; Tue, 01 Jun 2021 03:12:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622542346; cv=none; d=google.com; s=arc-20160816; b=GuvXrvTya/p6eOLXusTchYRg7RaKsUuPKRwDOd3lVfjpW9YdSJ+pwOPMf+FLPZ76fv 42h9g7pX9kjCOzzp6DyMDewI+LzazsreB9FaprZdFaNOSOSrs8PLprw2Z2ANv7A0zyJc BW9bVGzrhz7sNd0G0t+RDk6QZ+PMQkvdGbEkTAbgeQb9cJZf6jGZxrJ2cZQFP+ZJ2Ohx W5hansNqOoEfUzwd1tYbWj9PawLhMhDhOMbpi6OvdijeHKzqUOMMz2dfeZROr+h/1QFv WGsgn10OIpOC6muNmPSYfQ5H/cM4XWW9qiwePLLvSUnOmdQ/U1SdSJ0L/K0WwuExDFp6 EfIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=QQzjn6gWwS/1TzPdRk9RzFgIOJWphaJXxjFq/6V+UBA=; b=yAkWIiYJw0sncPjwQ0VDFxNkoen6PjTib9PPZdKhNKIq2Q8BVfCNNoJURSKSs82zDH hjwk7yphWgwqnQfoFkrGrryS7zhokCiRNebtqzpGTM+vjV9YBtGx7/c6u2TPVHqZymA/ x3CgVZkUkNFjcgy50ElRfSlCdZtmis4DZU5vdEJ2mh4f/ZgzDsanhWUi9MouMuesAkwy YnsfudDYTt8/6CqVlUmK8fMaKTap+qfzyV7e09nCBD47Eb3dsDH1akjzf2RSm5z7ARWs p99NO+a7QyFf+HiEuNSKp7PI40aOHO3Mh/EFDMSTB9GlJU+cr58HVTZYcdhKlK7t8oH/ DSRA== 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 d4si15465511eja.217.2021.06.01.03.12.04; Tue, 01 Jun 2021 03:12:26 -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 S231542AbhFAKMM (ORCPT + 99 others); Tue, 1 Jun 2021 06:12:12 -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