On 06/24/2013 05:50 PM, Bart Van Assche wrote:
> On 06/24/13 15:48, Jack Wang wrote:
>>> I'm not sure it's possible to avoid such a race without introducing
>>> a new mutex. How about something like the (untested) SCSI core patch
>>> below, and invoking scsi_block_eh() and scsi_unblock_eh() around
On 06/24/13 15:48, Jack Wang wrote:
I'm not sure it's possible to avoid such a race without introducing
a new mutex. How about something like the (untested) SCSI core patch
below, and invoking scsi_block_eh() and scsi_unblock_eh() around any
reconnect activity not initiated from the SCSI EH threa
> I'm not sure it's possible to avoid such a race without introducing
> a new mutex. How about something like the (untested) SCSI core patch
> below, and invoking scsi_block_eh() and scsi_unblock_eh() around any
> reconnect activity not initiated from the SCSI EH thread ?
>
> [PATCH] Add scsi_bloc
On 06/23/13 23:13, Mike Christie wrote:
> On 06/12/2013 08:28 AM, Bart Van Assche wrote:
>> +/*
>> + * It can occur that after fast_io_fail_tmo expired and before
>> + * dev_loss_tmo expired that the SCSI error handler has
>> + * offlined one or more
On 06/12/2013 08:28 AM, Bart Van Assche wrote:
> + /*
> + * It can occur that after fast_io_fail_tmo expired and before
> + * dev_loss_tmo expired that the SCSI error handler has
> + * offlined one or more devices. scsi_target_unblock() doesn't
> +
On 06/19/2013 05:27 PM, Bart Van Assche wrote:
> On 06/19/13 15:44, Jack Wang wrote:
>>> +/*
>>> + * It can occur that after fast_io_fail_tmo expired and before
>>> + * dev_loss_tmo expired that the SCSI error handler has
>>> + * offlined one or more devices. doesn'
On 06/19/13 15:44, Jack Wang wrote:
+ /*
+* It can occur that after fast_io_fail_tmo expired and before
+* dev_loss_tmo expired that the SCSI error handler has
+* offlined one or more devices. scsi_target_unblock() doesn't
+
> + /*
> + * It can occur that after fast_io_fail_tmo expired and before
> + * dev_loss_tmo expired that the SCSI error handler has
> + * offlined one or more devices. scsi_target_unblock() doesn't
> + * change the state of these devic
On 06/18/13 18:59, Vu Pham wrote:
Bart Van Assche wrote:
On 06/14/13 19:59, Vu Pham wrote:
On 06/13/13 21:43, Vu Pham wrote:
If rport's state is already SRP_RPORT_BLOCKED, I don't think we need
to do extra block with scsi_block_requests()
Please keep in mind that srp_reconnect_rport() can be
Bart Van Assche wrote:
On 06/14/13 19:59, Vu Pham wrote:
On 06/13/13 21:43, Vu Pham wrote:
+/**
+ * srp_tmo_valid() - check timeout combination validity
+ *
+ * If no fast I/O fail timeout has been configured then the device
loss timeout
+ * must be below SCSI_DEVICE_BLOCK_MAX_TIMEOUT. If a fas
On 17.06.2013 09:29, Bart Van Assche wrote:
> On 06/17/13 09:14, Hannes Reinecke wrote:
>> On 06/17/2013 09:04 AM, Bart Van Assche wrote:
>>> I agree that the value of fast_io_fail_tmo should be kept small.
>>> Although as you explained changing the SCSI device state into
>>> SDEV_BLOCK doesn't hel
On 06/17/2013 09:29 AM, Bart Van Assche wrote:
> On 06/17/13 09:14, Hannes Reinecke wrote:
>> On 06/17/2013 09:04 AM, Bart Van Assche wrote:
>>> I agree that the value of fast_io_fail_tmo should be kept small.
>>> Although as you explained changing the SCSI device state into
>>> SDEV_BLOCK doesn't
On 06/17/13 09:14, Hannes Reinecke wrote:
On 06/17/2013 09:04 AM, Bart Van Assche wrote:
I agree that the value of fast_io_fail_tmo should be kept small.
Although as you explained changing the SCSI device state into
SDEV_BLOCK doesn't help for I/O that has already been queued on a
failed path, I
On 06/17/2013 09:04 AM, Bart Van Assche wrote:
> On 06/17/13 08:18, Hannes Reinecke wrote:
>> On 06/15/2013 11:52 AM, Bart Van Assche wrote:
[ .. ]
>>>
>>> I think the advantage of multipathd recognizing the SDEV_BLOCK state
>>> before the fast_io_fail_tmo timer has expired is important.
>>> Multip
On 06/17/13 08:18, Hannes Reinecke wrote:
On 06/15/2013 11:52 AM, Bart Van Assche wrote:
On 06/14/13 19:59, Vu Pham wrote:
On 06/13/13 21:43, Vu Pham wrote:
+/**
+ * srp_tmo_valid() - check timeout combination validity
+ *
+ * If no fast I/O fail timeout has been configured then the
device
los
On 06/15/2013 11:52 AM, Bart Van Assche wrote:
> On 06/14/13 19:59, Vu Pham wrote:
>>> On 06/13/13 21:43, Vu Pham wrote:
> +/**
> + * srp_tmo_valid() - check timeout combination validity
> + *
> + * If no fast I/O fail timeout has been configured then the
> device
> loss tim
On 06/14/13 19:59, Vu Pham wrote:
On 06/13/13 21:43, Vu Pham wrote:
+/**
+ * srp_tmo_valid() - check timeout combination validity
+ *
+ * If no fast I/O fail timeout has been configured then the device
loss timeout
+ * must be below SCSI_DEVICE_BLOCK_MAX_TIMEOUT. If a fast I/O fail
timeout has
+
Hello Bart,
On 06/13/13 21:43, Vu Pham wrote:
Hello Bart,
+What:/sys/class/srp_remote_ports/port-:/dev_loss_tmo
+Date:September 1, 2013
+KernelVersion:3.11
+Contact:linux-scsi@vger.kernel.org, linux-r...@vger.kernel.org
+Description:Number of seconds the SC
On 06/13/13 21:43, Vu Pham wrote:
> Hello Bart,
>
>>
>> +What:/sys/class/srp_remote_ports/port-:/dev_loss_tmo
>> +Date:September 1, 2013
>> +KernelVersion:3.11
>> +Contact:linux-scsi@vger.kernel.org, linux-r...@vger.kernel.org
>> +Description:Number of seconds the SCSI
Hello Bart,
+What: /sys/class/srp_remote_ports/port-:/dev_loss_tmo
+Date: September 1, 2013
+KernelVersion: 3.11
+Contact: linux-scsi@vger.kernel.org, linux-r...@vger.kernel.org
+Description: Number of seconds the SCSI layer will wait after a transport
+ layer e
20 matches
Mail list logo
