Re: [PATCH 1/2] don't wait on disk to start on resume

On 02/03/2013 02:23 PM, Aaron Lu wrote: > No, the modification is actually for disk. > With v8 of block layer runtime PM, it is no longer the case runtime > suspend is the same as system suspend for hard disk that utilize block > layer runtime PM: we quiesce the device and run its suspend callback

[PATCH 1/1] [SCSI] fnic: Remove unneeded version.h header file include

version.h header file inclusion is not necessary. Signed-off-by: Sachin Kamat --- drivers/scsi/fnic/fnic_trace.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/fnic/fnic_trace.c b/drivers/scsi/fnic/fnic_trace.c index 0b18bf4..63f6f5b 100644 --- a/drivers/sc

Re: [PATCH 1/2] don't wait on disk to start on resume

On 02/04/2013 08:07 AM, dbasehore . wrote: On the topic that we do a fast return for both scsi and ata. Now I don't remember everything about this (and correct me if I'm wrong) since I figured this out a few months ago. There are some dependencies that scsi has on the resume path of ata. I think

Re: [PATCH 2/2] Configure reported luns

Thanks for looking Mike. I agree on changing the GFP_ATOMIC to something less restrictive but wonder if NOIO is the right choice or not. See below. 02/01/2013 02:44 AM, Mike Christie wrote: On 01/28/2013 02:27 PM, Rob Evers wrote: Change default value of max_report_luns to 16k-1. Use data

[PATCH] SG_SCSI_RESET ioctl should only perform requested operation

>From all the documentation I've found, it is not clear that users of the SG_SCSI_RESET ioctl may have their requests progress up the hierarchy of reset operations. Basically, requests for a SCSI_TRY_RESET_DEVICE may eventually result in a TARGET, BUS, or HOST reset. The sg_reset utility hints at

Re: [PATCH] SG_SCSI_RESET ioctl should only perform requested operation

On 13-02-04 03:17 PM, Jeremy Linton wrote: From all the documentation I've found, it is not clear that users of the SG_SCSI_RESET ioctl may have their requests progress up the hierarchy of reset operations. Basically, requests for a SCSI_TRY_RESET_DEVICE may eventually result in a TARGET, BUS,

Re: [LSF/MM TOPIC] Thin provisioning SOFT_THRESHOLD error handling

On Tue, Jan 29, 2013 at 12:14 AM, Hannes Reinecke wrote: > I would like to discuss at LSF the possible implementations > and handling mechanism for this kind of failure scenarios. I'd be interested in that discussion. With my Pure hat on, our array can generate these thin provisioning threshold

Re: [LSF/MM TOPIC] I_T Nexus loss SCSI error handling

On Mon, Jan 21, 2013 at 3:18 AM, Hannes Reinecke wrote: > The current error handler still uses a 'target reset' (or, rather, bus > reset) strategy, although the respective TMF has been obsoleted since > SAM-3. SAM-5 defines an I_T nexus loss event instead, which so far has only > been implemented

Re: [LSF/MM TOPIC] Thin provisioning SOFT_THRESHOLD error handling

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/29/13 3:14 AM, Hannes Reinecke wrote: > Hi all, > > Thin-provisioned devices have the ability to set a 'soft > threshold', which is triggered if the real free space for this > device is beyond this mark. > > The intention behind this is to allow

[LSF/MM] iSER Target implementation for v3.10

Hi folks, [Topic] iSER Target implementation for upstream in v3.10 timeframe [Abstract] I'm currently working on a kernel level iSCSI Extensions for RDMA (iSER) target driver using OFA Verbs for Infiniband + Ethernet based transports. This naturally involves quite a bit of re-factoring + creat

Re: [LSF/MM TOPIC] Making sure soft SCSI Targets are Valid

On Tue, 2013-01-29 at 11:13 -0800, Lee Duncan wrote: > Hi: > > I'm not sure if there is much interest in this, but I've recently > realized that there is no good free software to validate iSCSI targets, > not to mention FCOE targets, IB soft targets, etc. There's just no way > to know if any chang