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
Add the necessary functions in the SRP transport module to allow
an SRP initiator driver to implement transport layer error handling
similar to the functionality already provided by the FC transport
layer. This includes:
- Support for implementing fast_io_fail_tmo, the time that should
elapse aft
21 matches
Mail list logo
