Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp733820pxf; Wed, 24 Mar 2021 14:47:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNYb3a6T8kKNsaVHXSZY+PBhsTRvXvKc+stwyX8QnbRFFoBAtbzlhlO7RHfyb3UDXQUZBC X-Received: by 2002:a17:906:2e45:: with SMTP id r5mr5754427eji.380.1616622452146; Wed, 24 Mar 2021 14:47:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616622452; cv=none; d=google.com; s=arc-20160816; b=RHZ4TYSGCqHIBKDsxglv0y5/SzNlhN9P2hhtOb9hqWlbQQ+dHN4WGvAKaIvyDhkfQ1 7e2jblIuJxjsNctpnuX697GJOHmA+1byxe36VfSjtzYf5haTfPa+LZf28RK0DGnyq31V KSV5gte3OZlFKT+EI5k9mJXhJ1gJrTLWJxmDOd/E9adDZBafOKxZ3C5CaieLuVnSB3ji ydAEpaAf/wC8qVQiS5ivcCgcSkUSyFBNNFZxTeBk/ypwLsWfoO5pz4+JyaWu26rR7JZ/ Ieb+TyfMyMd4w3Yav9sXw7FrSDLKx6j+kTa2isqT97coW8MoYVLV+mHuIUYbMcYox7L0 lAig== 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=wtjq8X9SCSyDKsKQn9c7RLHcNPk9SfUR6E1+5kDz2s0=; b=WBELhpawZKpiGFFpjmN+uoosv3ADxM3iJVnRCkQbZW8hagDA8s+jzgfPVeCRX0NFb6 PEmgdsEJtl3HjIRLlr7u2H2f6jdP2pbsruQu28fD+7Qe4pgYJ8vUajVZ+HAXPXvpoY9F gvPBR9/g+IFwF1QPdCGf+Nlr7BuTvPAmkV+at3pcayi9zswpiMK109EUef+0fQuntAjg rGH8bVntr9bgnGm5fTXjrB1wdpePDou0Ls9C/Mi2jnGKoNnr1aJIjRL7j68WSNqbDrQl nSPiU8IrmNoDlA1/RA8YcYddBP6p6VL3M/o2ZR9vkLGMqV2+h2iW8wobR61CFEZlvMWg Gaig== 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 yd6si2724697ejb.302.2021.03.24.14.47.09; Wed, 24 Mar 2021 14:47:32 -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 S231895AbhCXB5u (ORCPT + 99 others); Tue, 23 Mar 2021 21:57:50 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:14133 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231278AbhCXB5o (ORCPT ); Tue, 23 Mar 2021 21:57:44 -0400 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4F4rt72MRJz19Hj0; Wed, 24 Mar 2021 09:55:43 +0800 (CST) Received: from [10.136.110.154] (10.136.110.154) by smtp.huawei.com (10.3.19.204) with Microsoft SMTP Server (TLS) id 14.3.498.0; Wed, 24 Mar 2021 09:57:39 +0800 Subject: Re: [PATCH] Revert "f2fs: give a warning only for readonly partition" To: Jaegeuk Kim CC: , , References: <20210323064155.12582-1-yuchao0@huawei.com> From: Chao Yu Message-ID: <107e671d-68ea-1a74-521e-ab2b6fe36416@huawei.com> Date: Wed, 24 Mar 2021 09:57:38 +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/3/24 2:39, Jaegeuk Kim wrote: > On 03/23, Chao Yu wrote: >> This reverts commit 938a184265d75ea474f1c6fe1da96a5196163789. >> >> Because that commit fails generic/050 testcase which expect failure >> during mount a recoverable readonly partition. > > I think we need to change generic/050, since f2fs can recover this partition, Well, not sure we can change that testcase, since it restricts all generic filesystems behavior. At least, ext4's behavior makes sense to me: journal_dev_ro = bdev_read_only(journal->j_dev); really_read_only = bdev_read_only(sb->s_bdev) | journal_dev_ro; if (journal_dev_ro && !sb_rdonly(sb)) { ext4_msg(sb, KERN_ERR, "journal device read-only, try mounting with '-o ro'"); err = -EROFS; goto err_out; } if (ext4_has_feature_journal_needs_recovery(sb)) { if (sb_rdonly(sb)) { ext4_msg(sb, KERN_INFO, "INFO: recovery " "required on readonly filesystem"); if (really_read_only) { ext4_msg(sb, KERN_ERR, "write access " "unavailable, cannot proceed " "(try mounting with noload)"); err = -EROFS; goto err_out; } ext4_msg(sb, KERN_INFO, "write access will " "be enabled during recovery"); } } > even though using it as readonly. And, valid checkpoint can allow for user to > read all the data without problem. >> if (f2fs_hw_is_readonly(sbi)) { Since device is readonly now, all write to the device will fail, checkpoint can not persist recovered data, after page cache is expired, user can see stale data. Am I missing something? Thanks, > >> >> Fixes: 938a184265d7 ("f2fs: give a warning only for readonly partition") >> Signed-off-by: Chao Yu >> --- >> fs/f2fs/super.c | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c >> index b48281642e98..2b78ee11f093 100644 >> --- a/fs/f2fs/super.c >> +++ b/fs/f2fs/super.c >> @@ -3952,10 +3952,12 @@ static int f2fs_fill_super(struct super_block *sb, void *data, int silent) >> * previous checkpoint was not done by clean system shutdown. >> */ >> if (f2fs_hw_is_readonly(sbi)) { >> - if (!is_set_ckpt_flags(sbi, CP_UMOUNT_FLAG)) >> + if (!is_set_ckpt_flags(sbi, CP_UMOUNT_FLAG)) { >> + err = -EROFS; >> f2fs_err(sbi, "Need to recover fsync data, but write access unavailable"); >> - else >> - f2fs_info(sbi, "write access unavailable, skipping recovery"); >> + goto free_meta; >> + } >> + f2fs_info(sbi, "write access unavailable, skipping recovery"); >> goto reset_checkpoint; >> } >> >> -- >> 2.29.2 > . >