On Tue, Jan 08, 2019 at 12:32:43PM +0100, Martin Wilck wrote:
> Hi Christophe,
>
> my late NVMe patch series broke compilatioin with older
> kernel headers. This series fixes that, and adds two other
> minor build-related fixes.
>
> Regards,
> Martin
ACK for the set
-Ben
>
> Martin Wilck (3):
On Fri, Jan 04, 2019 at 06:59:10PM +0100, Martin Wilck wrote:
> Chonyun Wu's latest patch has shown that the handling of the daemon
> state variable running_state is racy and difficult to get right. It's
> not a good candidate for a "benign race" annotation. So, as a first
> step to sanitizing it,
On Fri, Jan 04, 2019 at 06:59:09PM +0100, Martin Wilck wrote:
> From: Chongyun Wu
>
> Test environment: 25 hosts, each host have more than 100 luns,
> each lun have two paths.
> Some times when we try to ceate new multipath will encounter "could
> not create uxsock:98" but the multipathd still ru
On Fri, Jan 04, 2019 at 06:59:14PM +0100, Martin Wilck wrote:
> The uxlsnr thread is responsible for receiving and handling
> signals in multipathd. This works well while it is idle and
> waiting for connections in ppoll(). But if it's busy, cli commands
> may need to take the vecs lock, which migh
On Fri, Jan 04, 2019 at 06:59:13PM +0100, Martin Wilck wrote:
> multipathd blocks all signals except in the uxlsnr thread.
> Add some code to handle signals even while they're blocked.
>
> If a shutdown signal is received, deliver_pending_signals() returns
> TRUE. This is not the same as should_ex
On Fri, Jan 04, 2019 at 06:59:12PM +0100, Martin Wilck wrote:
> Cancel the other threads before taking vecs->lock. This avoids
> delays during shutdown caused e.g. by the checker thread holding
> the vecs lock.
Before this change, multipathd was guaranteed that once a thread had
locked the vecs lo
On Fri, Jan 04, 2019 at 06:59:11PM +0100, Martin Wilck wrote:
> reconfigure() can be a long-running operation; both initial path
> discovery and initial map setup can take a long time. Allow
> the main program to indicate that the process should be
> interrupted if a shutdown signal was received.
>
+dm-devel
I think I have made some progress here. One of my colleagues ran a test
with tracepoints on and I spotted that the last write has its flags
flipped compared to the other writes:
fstrim-18019 [022] 91107.302026: bcache_write:
73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4260112
