Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1484092

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

From Alex Bligh <alex@alex.org.uk>
Newsgroups linux.kernel
Subject Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements
Date 2016-09-15 14:20 +0200
Message-ID <shDO2-6VP-29@gated-at.bofh.it> (permalink)
References (1 earlier) <sfArf-7zf-11@gated-at.bofh.it> <shCyC-5VC-15@gated-at.bofh.it> <shDl0-6rX-13@gated-at.bofh.it> <shDuG-6vN-55@gated-at.bofh.it> <shDEm-6P5-45@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

Christoph,

> 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

Ah! the bit you are complaining about is not the bit I pointed to you, but:

> NBD_CMD_FLUSH (3)
> 
> A flush request; a write barrier. 

I can see that's potentially confusing as isn't meant to mean 'an old-style
linux kernel block device write barrier'. I think in general terms it
probably is some form of barrier, but I see no problem in deleting the
words "a write barrier" from the spec text if only to make it
clearer. However, I think the description of the command itself:

> The server MUST NOT send a successful reply header for this request before all write requests for which a reply has already been sent to the client have reached permanent storage (using fsync() or similar).

and the ordering section I pointed you to before, were both correct, yes?


>> 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.

... that's what it says (I hope).

> 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.

actually fdatasync() technically does more than is necessary, as it
will also flush commands that have been processed, but for which no
reply has yet been sent - that's no bad thing.

-- 
Alex Bligh

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst <w@uter.be> - 2016-09-09 22:20 +0200
  Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst <w@uter.be> - 2016-09-09 23:00 +0200
    Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Jens Axboe <axboe@kernel.dk> - 2016-09-10 01:40 +0200
  Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst <w@uter.be> - 2016-09-15 13:00 +0200
    Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 13:20 +0200
      Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst <w@uter.be> - 2016-09-15 13:40 +0200
        Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 13:50 +0200
          Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 13:50 +0200
            Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 14:00 +0200
              Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst <w@uter.be> - 2016-09-15 14:10 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 14:30 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 14:30 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst <w@uter.be> - 2016-09-15 14:30 +0200
              Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 14:10 +0200
      Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 13:40 +0200
      Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Eric Blake <eblake@redhat.com> - 2016-09-15 15:40 +0200
        Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Paolo Bonzini <pbonzini@redhat.com> - 2016-09-15 16:10 +0200
          Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 17:30 +0200
            Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Paolo Bonzini <pbonzini@redhat.com> - 2016-09-15 23:20 +0200
        Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 17:30 +0200
    Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 13:50 +0200
      Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 14:00 +0200
    Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 13:50 +0200
    Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst <w@uter.be> - 2016-09-15 14:00 +0200
      Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 14:10 +0200
        Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 14:20 +0200
          Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 14:20 +0200
            Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 14:30 +0200
        Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst <w@uter.be> - 2016-09-15 14:30 +0200
          Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 14:30 +0200
            Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 14:40 +0200
              Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 14:40 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 14:50 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 14:50 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst <w@uter.be> - 2016-09-15 15:20 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 17:20 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 18:10 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Wouter Verhelst <w@uter.be> - 2016-09-15 18:30 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Alex Bligh <alex@alex.org.uk> - 2016-09-15 18:50 +0200
                Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Eric Blake <eblake@redhat.com> - 2016-09-15 21:10 +0200
              Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 14:40 +0200
    Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements Christoph Hellwig <hch@infradead.org> - 2016-09-15 14:20 +0200

csiph-web