From: Chao Yu <chao@kernel.org>
To: 红烧的威化饼 <glqhw@qq.com>,
linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [f2fs-dev] Potential data corruption?
Date: Sun, 8 Dec 2019 12:00:56 +0800 [thread overview]
Message-ID: <4ef45a4b-47fa-4d7e-a060-4cad56ca372a@kernel.org> (raw)
In-Reply-To: <tencent_0B38BD6C2739091DE8A052D6D772D1DEAA06@qq.com>
Hello,
On 2019-12-7 18:10, 红烧的威化饼 wrote:
> Hi F2FS experts,
> The following confuses me:
>
> A typical fsync() goes like this:
> 1) Issue data block IOs
> 2) Wait for completion
> 3) Issue chained node block IOs
> 4) Wait for completion
> 5) Issue flush command
>
> In order to preserve data consistency under sudden power failure, it requires that the storage device persists data blocks prior to node blocks.
> Otherwise, under sudden power failure, it's possible that the persisted node block points to NULL data blocks.
Firstly it doesn't break POSIX semantics, right? since fsync() didn't return
successfully before sudden power-cut, so we can not guarantee that data is fully
persisted in such condition.
However, what you want looks like atomic write semantics, which mostly database
want to guarantee during db file update.
F2FS has support atomic_write via ioctl, which is used by SQLite officially, I
guess you can check its implementation detail.
Thanks,
>
> However, according to this study (https://www.usenix.org/conference/fast18/presentation/won), the persistent order of requests doesn't necessarily equals to the request finish order (due to device volatile caches). This means that its possible that the node blocks get persisted prior to data blocks.
>
> Does F2FS have other mechanisms to prevent such inconsistency? Or does it require the device to persist data without reordering?
>
> Thanks!
>
> Hongwei
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2019-12-08 4:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-07 10:10 [f2fs-dev] Potential data corruption? =?gb18030?B?uuzJ1bXEzf67r7H9?=
2019-12-08 4:00 ` Chao Yu [this message]
2019-12-08 13:15 ` Hongwei Qin
2019-12-08 13:41 ` Chao Yu
2019-12-08 13:51 ` Gao Xiang via Linux-f2fs-devel
2019-12-09 10:46 ` Chao Yu
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=4ef45a4b-47fa-4d7e-a060-4cad56ca372a@kernel.org \
--to=chao@kernel.org \
--cc=glqhw@qq.com \
--cc=linux-f2fs-devel@lists.sourceforge.net \
/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).