Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp4138427pxv; Mon, 19 Jul 2021 18:08:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2mwRBmha6lfIeVMQn8Vq9zR+NBGeBNNtaiH8gNm8Td7GAUIbaxzI6o6i1vqxw4GarKKBe X-Received: by 2002:a17:906:f8d7:: with SMTP id lh23mr30153513ejb.485.1626743336476; Mon, 19 Jul 2021 18:08:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626743336; cv=none; d=google.com; s=arc-20160816; b=ma1o5vJLErOUfdMuhoGBYKAtZoEVfGRlKXbhLlf7FdMMYXbfnpfJiv4tgZqGJ0tp7B OD0ZQpJNJ4xw63dLDGkSaPINHNIrkYIxPBAwEpNWIGpUlDQuohhuy6yiI9FuokWZ6kPh ey8gm4WubkPwGqA03GGyBgeCz0nBs2kwlT0MtwUX3o5hP79Re0evKFP5/1uHF0fLQ+t9 PKBrVV9DkfI5VeiXIwNn+iWqOqovWq69Nl4fqxZ2rw0maAwem+4PlEo9+De2KGAKLTKJ FBvJkyRQDBN4uYenf3Y2NCwgDVDUlYAgO+WJcI88OnNFhKHEgejLAorK/h/y3lU0Kt4Y NJew== 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:dkim-signature; bh=6tEyrdEH+pfsiArjSMxf1OGG+7Pt2ct8m9gjU9+CYt4=; b=QONy85p2nFw9eQuaajN3QCcoBQIaE/BFHSloZmQqhcVrNiEq4JyssuFxOISXbKbFgc zFDQ3U6DJIQxqwodAmqI1TJwzNJsuPEePMpyai+fa+2NoXtwifOrDcKk5Lu9wfrRJkpR 4/tDMfX0dbeXziwlKYYozj9iCmT5w76MqWMHpjTO2CLO8iznifZGcRR6YO4IbOcl0nrs v9lOy3RVbZ2nA2xrAvYYNnDuIPMueivIWrUrkxEUx0UfGmFqJ120i7eO5RniRseujHff VtRUBmPFkWkMSx6RUyd1R9TxFwpD46UoJ5VBc+f4xxv4pCEwVTl7mlGM/VsEXjX5H5kx mCgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HMZkCFsb; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ck13si14591791ejb.145.2021.07.19.18.08.33; Mon, 19 Jul 2021 18:08:56 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HMZkCFsb; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239332AbhGTAZk (ORCPT + 99 others); Mon, 19 Jul 2021 20:25:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:40846 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240609AbhGTAXA (ORCPT ); Mon, 19 Jul 2021 20:23:00 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CAD4A6108B; Tue, 20 Jul 2021 01:03:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626743019; bh=pW7dgvX8qNpOLEnDjntqz8ri5q5ehXQ54m1Yym7YAoU=; h=From:To:Cc:Subject:Date:From; b=HMZkCFsbIHvDiufTmXl4sfDXppA63ordedFTPOo5V9twOlfKNpYi4iOrKZpeyvSVM k5HESN425dyjLwuC43TMlu7h9Dq9Tr7LtTSPCuBAyBriSghPiDFDLiRgBUHjq30gWD IiRpEuJMq3OISvet0p2Bd0bBK1v2/p4LaQ+DtG63f5N5vxDjHDkh/FYxp6KREYgpJh lEEV4VfeSQev5m5dydFuLeYooMMmcTWIlScvYJR9tiWobKh1EfJLeoUNoUXDbJiZqS Jpq+Bx1pweKPbfruWdg0txB/X8j2338n8L7Uz+tv7OiM1IBzc+9jfqaJujCEb45o1c mQNlrNTCQ815A== From: Chao Yu To: jaegeuk@kernel.org Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Chao Yu , Chao Yu Subject: [PATCH v3] f2fs: fix to force keeping write barrier for strict fsync mode Date: Tue, 20 Jul 2021 09:03:29 +0800 Message-Id: <20210720010329.3975-1-chao@kernel.org> X-Mailer: git-send-email 2.22.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 use atomic write sematics to keep write order in between data/node and last node, so that it avoids potential data corruption during fsync(). Signed-off-by: Chao Yu --- fs/f2fs/file.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 6afd4562335f..00b45876eaa1 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -301,6 +301,18 @@ 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 use atomic write sematics + * to keep write order in between data/node and last node to + * avoid potential data corruption. + */ + if (F2FS_OPTION(sbi).fsync_mode == + FSYNC_MODE_STRICT && !atomic) + atomic = true; } go_write: /* -- 2.22.1