linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Vijay Chidambaram <vijay@cs.utexas.edu>,
	lsf-pc@lists.linux-foundation.org,
	"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: Thu, 9 May 2019 11:47:15 +0300	[thread overview]
Message-ID: <CAOQ4uxgJZJaMNNSGeS9uw1JUVtRA9vWfUWDrYnFY4uZh6BeX2A@mail.gmail.com> (raw)
In-Reply-To: <20190509014327.GT1454@dread.disaster.area>

On Thu, May 9, 2019 at 4:43 AM Dave Chinner <david@fromorbit.com> wrote:
>
> On Thu, May 02, 2019 at 10:30:43PM -0400, Theodore Ts'o wrote:
> > On Thu, May 02, 2019 at 01:39:47PM -0400, Amir Goldstein wrote:
> > > I am not saying there is no room for a document that elaborates on those
> > > guaranties. I personally think that could be useful and certainly think that
> > > your group's work for adding xfstest coverage for API guaranties is useful.
> >
> > Again, here is my concern.  If we promise that ext4 will always obey
> > Dave Chinner's SOMC model, it would forever rule out Daejun Park and
> > Dongkun Shin's "iJournaling: Fine-grained journaling for improving the
> > latency of fsync system call"[1] published in Usenix ATC 2017.
>
> No, it doesn't rule that out at all.
>

Dave and all the good people,

Please go back to read the first email in this thread before it diverged yet
again into interpretations of SOMC.

The novelty in my proposal (which I attribute to Jan's idea) is to reduce the
concerns around documenting "expected behavior of the world" to documenting
"expected behavior of linking an O_TMPFILE".

It boils down to documenting AT_LINK_ATOMIC (or whatever flag name):

""The filesystem provided the guaranty that after a crash, if the linked
 O_TMPFILE is observed in the target directory, than all the data and
 metadata modifications made to the file before being linked are also
 observed."

No more, no less.

I intentionally reduced the scope to the point that I could get ext4,btrfs to
sign the treaty. I think this is a good starting point, from which we can make
forward progress.

I'd appreciate if xfs camp, Dave in particular, would address the proposal
regardless of the broader SOMC documentation discussion.

Thanks,
Amir.

  parent reply	other threads:[~2019-05-09  8:47 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
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 [this message]
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=CAOQ4uxgJZJaMNNSGeS9uw1JUVtRA9vWfUWDrYnFY4uZh6BeX2A@mail.gmail.com \
    --to=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=tytso@mit.edu \
    --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).