All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Wouter Verhelst <w@uter.be>
Cc: Christoph Hellwig <hch@infradead.org>,
	nbd-general@lists.sourceforge.net, Josef Bacik <jbacik@fb.com>,
	linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	mpa@pengutronix.de, kernel-team@fb.com
Subject: Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements
Date: Thu, 15 Sep 2016 05:01:25 -0700	[thread overview]
Message-ID: <20160915120125.GA31044@infradead.org> (raw)
In-Reply-To: <20160915115514.7hba23nqvvwfhb5z@grep.be>

On Thu, Sep 15, 2016 at 01:55:14PM +0200, Wouter Verhelst wrote:
> Maybe I'm not using the correct terminology here. The point is that
> after a FLUSH, the server asserts that all write commands *for which a
> reply has already been sent to the client* will also have reached
> permanent storage. Nothing is asserted about commands for which the
> reply has not yet been sent, regardless of whether they were sent to the
> server before or after the FLUSH; they may reach permanent storage as a
> result of the FLUSH, or they may not, we don't say.
> 
> With FUA, we only assert that the FUA-flagged command reaches permanent
> storage before its reply is sent, nothing else.

Yes, that's the correct semantics.

> If that's not a write barrier, then I was using the wrong terminology
> (and offer my apologies for the confusion).

It's not a write barrier - a write barrier was command that ensured that

 a) all previous writes were completed to the host/client
 b) all previous writes were on non-volatile storage

and

 c) the actual write with the barrier bit was on non-volatile storage

> The point still remains that "X was sent before Y" is difficult to
> determine on the client side if X was sent over a different TCP channel
> than Y, because a packet might be dropped (requiring a retransmit) for
> X, and similar things. If blk-mq can deal with that, we're good and
> nothing further needs to be done. If not, this should be evaluated by
> someone more familiar with the internals of the kernel block subsystem
> than me.

The important bit in all the existing protocols, and which Linux relies
on is that any write the Linux block layer got a completion for earlier
needs to be flushed out to non-volatile storage when a FLUSH command is
set.  Anything that still is in flight does not matter.  Which for
NBD means anything that you already replies to need to be flushed.

Or to say it more practicly - in the nbd server you simply need to
call fdatasync on the backing device or file whenever you get a FLUSH
requires, and it will do the right thing.

  reply	other threads:[~2016-09-15 12:01 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-08 21:12 [RESEND][PATCH 0/5] nbd improvements Josef Bacik
2016-09-08 21:12 ` [PATCH 1/5] nbd: convert to blkmq Josef Bacik
2016-09-08 21:12 ` [PATCH 2/5] nbd: don't shutdown sock with irq's disabled Josef Bacik
2016-09-08 21:12 ` [PATCH 3/5] nbd: use flags instead of bool Josef Bacik
2016-09-09  1:20   ` Joe Perches
2016-09-09 13:55     ` Jens Axboe
2016-09-09 16:04       ` Joe Perches
2016-09-09 16:04         ` Joe Perches
2016-09-09 16:11         ` Jens Axboe
2016-09-09 16:15           ` Joe Perches
2016-09-09 16:20             ` Jens Axboe
2016-09-09 16:20               ` Jens Axboe
2016-09-08 21:12 ` [PATCH 4/5] nbd: allow block mq to deal with timeouts Josef Bacik
2016-09-08 21:12 ` [PATCH 5/5] nbd: add multi-connection support Josef Bacik
2016-09-10  7:43   ` Christoph Hellwig
2016-09-12 13:11     ` Josef Bacik
2016-09-09 20:02 ` [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst
2016-09-09 20:36   ` Josef Bacik
2016-09-09 20:55     ` Wouter Verhelst
2016-09-09 23:00       ` Josef Bacik
2016-09-09 23:37         ` Jens Axboe
2016-09-15 10:49   ` Wouter Verhelst
2016-09-15 11:09     ` Alex Bligh
2016-09-15 11:09       ` Alex Bligh
2016-09-15 11:29       ` Wouter Verhelst
2016-09-15 11:29         ` Wouter Verhelst
2016-09-15 11:40         ` Christoph Hellwig
2016-09-15 11:40           ` Christoph Hellwig
2016-09-15 11:46           ` Alex Bligh
2016-09-15 11:46             ` Alex Bligh
2016-09-15 11:52             ` Christoph Hellwig
2016-09-15 11:52               ` Christoph Hellwig
2016-09-15 12:01               ` Wouter Verhelst
2016-09-15 12:01                 ` Wouter Verhelst
2016-09-15 12:20                 ` Christoph Hellwig
2016-09-15 12:20                   ` Christoph Hellwig
2016-09-15 12:26                   ` Wouter Verhelst
2016-09-15 12:26                     ` Wouter Verhelst
2016-09-15 12:27                     ` Christoph Hellwig
2016-09-15 12:27                       ` Christoph Hellwig
2016-09-15 12:04               ` Alex Bligh
2016-09-15 12:04                 ` Alex Bligh
2016-09-15 11:39       ` Christoph Hellwig
2016-09-15 11:39         ` Christoph Hellwig
2016-09-15 13:34       ` Eric Blake
2016-09-15 13:34         ` Eric Blake
2016-09-15 14:07         ` Paolo Bonzini
2016-09-15 14:07           ` Paolo Bonzini
2016-09-15 15:23           ` Alex Bligh
2016-09-15 15:23             ` Alex Bligh
2016-09-15 21:10             ` Paolo Bonzini
2016-09-15 21:10               ` Paolo Bonzini
2016-09-15 15:25         ` Alex Bligh
2016-09-15 15:25           ` Alex Bligh
2016-09-15 11:38     ` Christoph Hellwig
2016-09-15 11:43       ` Alex Bligh
2016-09-15 11:43         ` Alex Bligh
2016-09-15 11:46         ` Christoph Hellwig
2016-09-15 11:46           ` Christoph Hellwig
2016-09-15 11:56           ` Alex Bligh
2016-09-15 11:56             ` Alex Bligh
2016-09-15 11:55       ` Wouter Verhelst
2016-09-15 12:01         ` Christoph Hellwig [this message]
2016-09-15 12:11           ` Alex Bligh
2016-09-15 12:11             ` Alex Bligh
2016-09-15 12:18             ` Christoph Hellwig
2016-09-15 12:18               ` Christoph Hellwig
2016-09-15 12:28               ` Alex Bligh
2016-09-15 12:28                 ` Alex Bligh
2016-09-15 12:21           ` Wouter Verhelst
2016-09-15 12:23             ` Christoph Hellwig
2016-09-15 12:33               ` Alex Bligh
2016-09-15 12:33                 ` Alex Bligh
2016-09-15 12:36                 ` Christoph Hellwig
2016-09-15 12:36                   ` Christoph Hellwig
2016-09-15 12:39                   ` Alex Bligh
2016-09-15 12:39                     ` Alex Bligh
2016-09-15 12:41                     ` Christoph Hellwig
2016-09-15 12:41                       ` Christoph Hellwig
2016-09-15 12:44                       ` Alex Bligh
2016-09-15 12:44                         ` Alex Bligh
2016-09-15 13:17                         ` Wouter Verhelst
2016-09-15 13:17                           ` Wouter Verhelst
2016-09-15 13:57                           ` Josef Bacik
2016-09-15 13:57                             ` Josef Bacik
2016-09-15 15:17                             ` Alex Bligh
2016-09-15 15:17                               ` Alex Bligh
2016-09-15 16:08                           ` Alex Bligh
2016-09-15 16:08                             ` Alex Bligh
2016-09-15 16:27                             ` Wouter Verhelst
2016-09-15 16:27                               ` Wouter Verhelst
2016-09-15 16:42                               ` Alex Bligh
2016-09-15 16:42                                 ` Alex Bligh
2016-09-15 19:02                               ` Eric Blake
2016-09-15 19:02                                 ` Eric Blake

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=20160915120125.GA31044@infradead.org \
    --to=hch@infradead.org \
    --cc=jbacik@fb.com \
    --cc=kernel-team@fb.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpa@pengutronix.de \
    --cc=nbd-general@lists.sourceforge.net \
    --cc=w@uter.be \
    /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.