On 12/07/2016 07:42 AM, peng.lia...@zte.com.cn wrote:
> Hello, Ben
>
> Sorry for late to reply.
>
> Such is the case as you said below. If fast_io_fail_tmo is off we have
> to cap dev_loss_tmo at 600. So, this patch is a wrong guide and will be
> cause a kernel error.
>
Indeed.
We've had _far_
Hello, Ben
Sorry for late to reply.
Such is the case as you said below. If fast_io_fail_tmo is off we have to cap
dev_loss_tmo at 600. So, this patch is a wrong guide and will be cause a
kernel error.
And one more question. Should the system limit dev_loss_tmo to 600 if
fast_io_fail_tmo set
On Mon, Dec 05 2016 at 5:50pm -0500,
Jens Axboe wrote:
> On 12/05/2016 03:40 PM, Mike Snitzer wrote:
> > On Mon, Dec 5, 2016 at 10:07 AM, Jens Axboe wrote:
> >>
> >> On 12/05/2016 06:05 AM, Christoph Hellwig wrote:
> >>> On Fri, Dec 02, 2016 at 08:15:15PM -0700,
On Tue, Dec 06, 2016 at 04:11:42PM +0100, Xose Vazquez Perez wrote:
> On 10/29/2016 04:55 AM, Benjamin Marzinski wrote:
>
> > Multipathd uses retrigger_tries to give udev more chances to to fill in
> > the uid_attribute, so that the path device is correctly set up in the
> > udev database.
On 10/29/2016 04:55 AM, Benjamin Marzinski wrote:
> Multipathd uses retrigger_tries to give udev more chances to to fill in
> the uid_attribute, so that the path device is correctly set up in the
> udev database. However the multipath command can't do this, so it should
> just immediately give up
On 11/27/2016 12:00 AM, Bart Van Assche wrote:
> On 11/26/16 14:26, Xose Vazquez Perez wrote:
>> Is there anything else missing or leftover?
>> $ git grep "(CC)"
>> Makefile.inc: $(CC) $(CFLAGS) -c -o $@ $<
>> kpartx/Makefile:$(CC) $(CFLAGS) $(OBJS) -o $(EXEC) $(LDFLAGS)
>>