lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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