[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAxjCEymRj+FQ-Zw1OAKVoh5LE=dwvy6PRU_BwxCoFZ6r0usyw@mail.gmail.com>
Date: Fri, 11 Jan 2019 10:24:18 +0100
From: Stefan Ring <stefanrin@...il.com>
To: Kurt Miller <kurt@...ricatesoftware.com>
Cc: linux-xfs@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: Block device flush ordering
On Thu, Jan 10, 2019 at 3:31 PM Kurt Miller <kurt@...ricatesoftware.com> wrote:
>
> For a well behaved block device that has a writeback cache,
> what is the proper behavior of flush when there are more
> then one outstanding flush operations? Is it;
>
> Flush all writes seen since the last flush.
> or
> Flush all writes received prior to the flush including
> those before any prior flush.
>
> For example take the following order of requests presented
> to the block device:
>
> writes 1-5
> flush 1
> write 6
> flush 2
>
> Can flush 2 finish with success as soon as write 6 is flushed
> (which may be before flush 1 success)? Or must it wait for
> all prior write operations to flush (writes 1-6)?
>
> This question has come up in our implementation of an NBD
> user-space block device and have not found a definitive answer
> on which behavior is correct for us to conform to. We want to
> ensure we behave as required for file-system commit write
> ordering.
As an interested outstanding observer who has had a bit of exposure to
memory models I would pose the question differently: Should flushes be
allowed to execute concurrently or should there be a total order? If a
total order is imposed, the premise of the question does not exist,
and otherwise I cannot see a single good reason to "wait for all prior
write operations to flush" because the second thread (the one
executing write 6 and flush 2) cannot even determine in a non-esoteric
way if another flush is ongoing or not.
Powered by blists - more mailing lists