Re: [LSF/MM TOPIC] Reducing the SRP initiator failover time

2013-02-08 Thread Sagi Grimberg
On 2/8/2013 12:42 AM, Vu Pham wrote: It is known that it takes about two to three minutes before the upstream SRP initiator fails over from a failed path to a working path. This is not only considered longer than acceptable but is also longer than other Linux SCSI initiators (e.g. iSCSI an

Re: [LSF/MM TOPIC][ATTEND] protection information and userspace

2013-02-08 Thread Joel Becker
On Thu, Feb 07, 2013 at 02:12:57PM -0500, Martin K. Petersen wrote: > > "Joel" == Joel Becker writes: > > Joel> I'm happy to chat about it. Unfortunately, like Darrick says, > Joel> sys_dio() coding hasn't happened. I do think we're better off > Joel> with some kind of explicit API than som

[LSF/MM TOPIC][ATTEND] protection information batched I/O interfaces.

2013-02-08 Thread Joel Becker
I'm definitely interested in attending to discuss PI injection from userspace, batched I/O interfaces, and potential O_DIRECT cleanups. Joel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majord...@vger.kernel.org More majordomo info at ht

Re: [LSF/MM TOPIC][ATTEND] protection information and userspace

2013-02-08 Thread Joel Becker
On Thu, Feb 07, 2013 at 04:04:36PM -0500, J. Bruce Fields wrote: > On Thu, Feb 07, 2013 at 09:36:39AM -0800, Joel Becker wrote: > > Dear LSF committee, > > I'd like to explicitly request attendance for this discussion > > :-) > > http://marc.info/?l=linux-fsdevel&m=135894412908342&w=2 > >

Re: [LSF/MM TOPIC] Reducing the SRP initiator failover time

2013-02-08 Thread Sebastian Riemer
On 08.02.2013 10:24, Sagi Grimberg wrote: > On 2/8/2013 12:42 AM, Vu Pham wrote: >> Hello Bart, >> >> Thank you for taking the initiative. >> Mellanox think that this should be discussed. We'd be happy to attend. >> >> We also would like to discuss: >> * How and how fast does SRP detect a path fail

[PATCH 1/3] target: Fix sense data for out-of-bounds IO operations

2013-02-08 Thread Roland Dreier
From: Roland Dreier We're supposed to return LOGICAL BLOCK ADDRESS OUT OF RANGE, not INVALID FIELD IN CDB. Signed-off-by: Roland Dreier --- drivers/target/target_core_sbc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/target_core_sbc.c b/drivers/target/tar

[PATCH 2/3] target: Fix error checking for UNMAP commands

2013-02-08 Thread Roland Dreier
From: Roland Dreier SBC-3 (revision 35) says: The PARAMETER LIST LENGTH field specifies the length in bytes of the UNMAP parameter list that is available to be transferred from the Data-Out Buffer. If the parameter list length is greater than zero and less than 0008h (i.e., eight

[PATCH 3/3] target: Fix parameter list length checking in MODE SELECT

2013-02-08 Thread Roland Dreier
From: Roland Dreier An empty parameter list (length == 0) is not an error, so succeed MODE SELECT in this case. If the parameter list length is too small, return the correct sense code of PARAMETER LIST LENGTH ERROR. Signed-off-by: Roland Dreier --- drivers/target/target_core_spc.c | 13 +

Re: [PATCH v8 0/10] More device removal fixes

2013-02-08 Thread Joe Lawrence
On Thu, 7 Feb 2013, Bart Van Assche wrote: > On 02/06/13 23:31, Joe Lawrence wrote: > > crash> list scsi_device.siblings -H 0x8808513a4290 -s scsi_device > > > > 880851232520 > > struct scsi_device { > >is_visible = 0x1, > >sdev_state = SDEV_DEL, > > } > > 880851235388 > > str