On 08/12/2016 02:36 PM, Benjamin Marzinski wrote:
On Fri, Aug 12, 2016 at 08:57:51AM -0700, Bart Van Assche wrote:
Subject: [PATCH] libmultipath, multipathd: Rework SIGPIPE handling
The behavior we want is as follows:
* If stdout is closed then multipathd stops due to SIGPIPE.
I still don't u
On Fri, Aug 12, 2016 at 08:57:51AM -0700, Bart Van Assche wrote:
> On 07/15/2016 02:35 PM, Benjamin Marzinski wrote:
> >On Tue, Jul 12, 2016 at 02:50:36PM +0800, Gris Ge wrote:
> >
> >The only thing that I wonder about with this patch is, when previously
> >the multipath client code would have fail
On 07/15/2016 02:35 PM, Benjamin Marzinski wrote:
On Tue, Jul 12, 2016 at 02:50:36PM +0800, Gris Ge wrote:
The only thing that I wonder about with this patch is, when previously
the multipath client code would have failed with EPIPE, and (at least in
some cases) spit out a semi-useful message, t
On Fri, Jul 15, 2016 at 04:35:45PM -0500, Benjamin Marzinski wrote:
> On Tue, Jul 12, 2016 at 02:50:36PM +0800, Gris Ge wrote:
>
> The only thing that I wonder about with this patch is, when previously
> the multipath client code would have failed with EPIPE, and (at least in
> some cases) spit ou
On Tue, Jul 12, 2016 at 02:50:36PM +0800, Gris Ge wrote:
The only thing that I wonder about with this patch is, when previously
the multipath client code would have failed with EPIPE, and (at least in
some cases) spit out a semi-useful message, the program will now
terminate because of the SIGPIPE
Problem:
mpath_recv_reply() return -EINVAL on command 'show maps json' with 2k paths.
Root cause:
Commit 174e717d351789a3cb29e1417f8e910baabcdb16 introduced the
limitation on max bytes(65535) of reply string from multipathd.
With 2k paths(1k mpaths) simulated by scsi_debug, the '
