linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Chao Yu <yuchao0@huawei.com>
To: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	"linux-f2fs-devel@lists.sourceforge.net"
	<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [f2fs-dev] [PATCH v4 2/2] fsck.f2fs: Check write pointer consistency with current segments
Date: Sat, 21 Sep 2019 17:42:11 +0800	[thread overview]
Message-ID: <6b6552a0-333b-872b-37b8-67e6bf0c1311@huawei.com> (raw)
In-Reply-To: <20190918030712.hko3pjm65glncqap@shindev.dhcp.fujisawa.hgst.com>

On 2019/9/18 11:07, Shinichiro Kawasaki wrote:
> Thanks for the comments. I read f2fs code further, and think still the
> SIT vs write pointer check can be implemented and meaningful.
> 
> F2fs ensures consistency of SIT using two CP areas, two SIT areas and
> sit_bitmap in CP. These metadata are in the conventional zone that not
> affected by write pointer control logic. My current scope is to ensure
> write pointer control logic correctness for zoned block device. From this
> scope and the f2fs SIT consistency feature, I would like to assume that
> SIT entries built in kernel after f2fs mount is correct for the write
> pointer position check.

SIT may be broken due to software bug or hardware flaw, we'd better not consider
it as a consistent metadata.

> 
> Fsck does additional SIT consistency check in fsck_chk_meta(). It would be
> good to do the write pointer position check at the end of fsck_chk_meta().

SIT can be changed later? e.g. SIT bitmap says one block address is valid,
however fsck found there is no entry can link to it, then it needs to be
deleted? it may affect write_pointer repair, right?

So we'd better look into all SIT update cases in fsck.

> 
>> - need to consider fsynced block in SIT
> 
> As far as I read fsync logic, fsync results in do_write_page() call which
> does both of SIT entry update and write bio submit. In other words, SIT
> update and write pointer move are expected for fsync also. Then I think
> the write pointer consistency check with last valid block obtained from
> SIT is meaningful, when I take fsynced blocks into account.

Yup, :)

Thanks,



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2019-09-21  9:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-30 10:19 [f2fs-dev] [PATCH v4 0/2] fsck: Check write pointers of zoned block devices Shin'ichiro Kawasaki
2019-08-30 10:19 ` [f2fs-dev] [PATCH v4 1/2] libf2fs_zoned: Introduce f2fs_report_zones() helper function Shin'ichiro Kawasaki
2019-08-30 10:19 ` [f2fs-dev] [PATCH v4 2/2] fsck.f2fs: Check write pointer consistency with current segments Shin'ichiro Kawasaki
2019-09-02  7:02   ` Chao Yu
2019-09-03  8:37     ` Shinichiro Kawasaki
2019-09-05  9:58       ` Chao Yu
2019-09-06  8:31         ` Shinichiro Kawasaki
2019-09-09  7:14           ` Chao Yu
2019-09-10  8:10             ` Shinichiro Kawasaki
2019-09-10  9:12               ` Chao Yu
2019-09-12  8:16                 ` Shinichiro Kawasaki
2019-09-16  1:37                   ` Chao Yu
2019-09-18  3:07                     ` Shinichiro Kawasaki
2019-09-21  9:42                       ` Chao Yu [this message]
2019-09-25  8:05                         ` Shinichiro Kawasaki
2019-09-29  2:09                           ` Chao Yu
2019-10-02  5:30                             ` Shinichiro Kawasaki
2019-10-18  6:55                               ` Shinichiro Kawasaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6b6552a0-333b-872b-37b8-67e6bf0c1311@huawei.com \
    --to=yuchao0@huawei.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=shinichiro.kawasaki@wdc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).