All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Sweet Tea Dorminy <sweettea@permabit.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: XFS journal write ordering constraints?
Date: Wed, 14 Jun 2017 08:16:47 +1000	[thread overview]
Message-ID: <20170613221647.GG17542@dastard> (raw)
In-Reply-To: <CALoZfD4RXJUusr7-r8COsUY+8_D6z68LbCRkp+9VM1E2tUV1UA@mail.gmail.com>

On Tue, Jun 13, 2017 at 10:14:10AM -0400, Sweet Tea Dorminy wrote:
> Thank you! I'm glad that we've established it's a mismatch between our
> device's implementation and XFS expectations.
> 
> >.... XFS issues log writes with REQ_PREFLUSH|REQ_FUA. This means
> >sequentially issued log writes have clearly specified ordering
> >constraints. i.e. the preflush completion order requirements means
> >that the block device must commit preflush+write+fua bios to stable
> >storage in the exact order they were issued by the filesystem....
> 
> That is certainly what REQ_BARRIER did back in the day. But when
> REQ_BARRIER was replaced with separate REQ_FUA and REQ_FLUSH
> flags, and barrier.txt got replaced with writeback_cache_control.txt,
> the documentation seemed to imply the ordering requirement on *issued*
> IO had gone away (but maybe I'm missing something).

Yes, that's my understanding, too, but I also thought that multiple
outstanding flushes are ordered by the block layer. i.e. flushes can
be reordered against other operations, but not other flushes.  I
could very well be wrong, but flush-to-flush ordering was what I
thought the ordered pending flush list for PREFLUSH requests in
blk_flush_complete_seq() did.

Like I said, Christoph is the expert here - he'll correct me if I'm
wrong.

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2017-06-13 22:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08 15:42 XFS journal write ordering constraints? Sweet Tea Dorminy
2017-06-09 12:38 ` Brian Foster
2017-06-09 17:30   ` Brian Foster
2017-06-09 23:44 ` Dave Chinner
2017-06-10  2:06   ` Sweet Tea Dorminy
2017-06-12 14:55     ` Brian Foster
2017-06-12 16:18       ` Brian Foster
2017-06-15 22:28         ` Sweet Tea Dorminy
2017-06-16 13:42           ` Brian Foster
2017-06-12 23:50     ` Dave Chinner
2017-06-13 14:14       ` Sweet Tea Dorminy
2017-06-13 22:16         ` Dave Chinner [this message]
2017-06-14  6:46           ` Christoph Hellwig
2017-06-13 16:29       ` Brian Foster

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=20170613221647.GG17542@dastard \
    --to=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sweettea@permabit.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.