From: "Theodore Ts'o" <tytso@mit.edu>
To: Vijay Chidambaram <vijay@cs.utexas.edu>
Cc: Amir Goldstein <amir73il@gmail.com>,
lsf-pc@lists.linux-foundation.org,
Dave Chinner <david@fromorbit.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Jan Kara <jack@suse.cz>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Jayashree Mohan <jaya@cs.utexas.edu>,
Filipe Manana <fdmanana@suse.com>, Chris Mason <clm@fb.com>,
lwn@lwn.net
Subject: Re: [TOPIC] Extending the filesystem crash recovery guaranties contract
Date: Fri, 3 May 2019 05:45:43 -0400 [thread overview]
Message-ID: <20190503094543.GD23724@mit.edu> (raw)
In-Reply-To: <CAHWVdUV115x8spvAd3p-6iDRE--yZULbF6DDc+Hapt2s+pJgbA@mail.gmail.com>
On Thu, May 02, 2019 at 10:15:01PM -0500, Vijay Chidambaram wrote:
>
> A few things to clarify:
> 1) We are not suggesting that all file systems follow SOMC semantics.
> If ext4 does not want to do so, we are quite happy to document ext4
> provides a different set of reasonable semantics. We can make the
> ext4-related documentation as minimal as you want (or drop ext4 from
> documentation entirely). I'm hoping this will satisfy you.
> 2) As I understand it, I do not think SOMC rules out the scenario in
> your example, because it does not require fsync to push un-related
> files to storage.
> 3) We are not documenting how fsync works internally, merely what the
> user-visible behavior is. I think this will actually free up file
> systems to optimize fsync aggressively while making sure they provide
> the required user-visible behavior.
As documented, the draft of the rules *I* saw specifically said that a
fsync() to inode B would guarantee that metadata changes for inode A,
which were made before the changes to inode B, would be persisted to
disk since the metadata changes for B happened after the changes to
inode A. It used the fsync(2) *explicitly* as an example for how
ordering of unrelated files could be guaranteed. And this would
invalidate Park and Shin's incremental journal for fsync.
If the guarantees are when fsync(2) is *not* being used, sure, then
the SOMC model is naturally what would happen with most common file
system. But then fsync(2) needs to appear nowhere in the crash
consistency model description, and that is not the case today.
Best regards,
- Ted
next prev parent reply other threads:[~2019-05-03 9:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-27 21:00 [TOPIC] Extending the filesystem crash recovery guaranties contract Amir Goldstein
2019-05-02 16:12 ` Amir Goldstein
2019-05-02 17:11 ` Vijay Chidambaram
2019-05-02 17:39 ` Amir Goldstein
2019-05-03 2:30 ` Theodore Ts'o
2019-05-03 3:15 ` Vijay Chidambaram
2019-05-03 9:45 ` Theodore Ts'o [this message]
2019-05-04 0:17 ` Vijay Chidambaram
2019-05-04 1:43 ` Theodore Ts'o
2019-05-07 18:38 ` Jan Kara
2019-05-03 4:16 ` Amir Goldstein
2019-05-03 9:58 ` Theodore Ts'o
2019-05-03 14:18 ` Amir Goldstein
2019-05-09 2:36 ` Dave Chinner
2019-05-09 1:43 ` Dave Chinner
2019-05-09 2:20 ` Theodore Ts'o
2019-05-09 2:58 ` Dave Chinner
2019-05-09 3:31 ` Theodore Ts'o
2019-05-09 5:19 ` Darrick J. Wong
2019-05-09 5:02 ` Vijay Chidambaram
2019-05-09 5:37 ` Darrick J. Wong
2019-05-09 15:46 ` Theodore Ts'o
2019-05-09 8:47 ` Amir Goldstein
2019-05-02 21:05 ` Darrick J. Wong
2019-05-02 22:19 ` Amir Goldstein
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=20190503094543.GD23724@mit.edu \
--to=tytso@mit.edu \
--cc=amir73il@gmail.com \
--cc=clm@fb.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=fdmanana@suse.com \
--cc=jack@suse.cz \
--cc=jaya@cs.utexas.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=lwn@lwn.net \
--cc=vijay@cs.utexas.edu \
/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).