linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Drivers: scsi
@ 2012-10-24 16:25 K. Y. Srinivasan
  2012-10-24 22:25 ` James Bottomley
  0 siblings, 1 reply; 6+ messages in thread
From: K. Y. Srinivasan @ 2012-10-24 16:25 UTC (permalink / raw)
  To: gregkh, linux-kernel, devel, ohering, jbottomley, hch, linux-scsi

When the low level driver returns SCSI_MLQUEUE_DEVICE_BUSY,
how is the command retried; I suspect the retry is done after some delay.
Is this delay programmable? If the device state changes,
can the low level driver notify upper layers that it can now handle
the command that it had failed earlier with SCSI_MLQUEUE_DEVICE_BUSY.

Regards,

K. Y

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Drivers: scsi
  2012-10-24 16:25 Drivers: scsi K. Y. Srinivasan
@ 2012-10-24 22:25 ` James Bottomley
  2012-10-24 22:34   ` KY Srinivasan
  0 siblings, 1 reply; 6+ messages in thread
From: James Bottomley @ 2012-10-24 22:25 UTC (permalink / raw)
  To: K. Y. Srinivasan; +Cc: gregkh, linux-kernel, devel, ohering, hch, linux-scsi

On Wed, 2012-10-24 at 09:25 -0700, K. Y. Srinivasan wrote:
> When the low level driver returns SCSI_MLQUEUE_DEVICE_BUSY,
> how is the command retried; I suspect the retry is done after some delay.

Delay depends mainly on I/O pressure and the unplug timer in the block
layer.

> Is this delay programmable? If the device state changes,
> can the low level driver notify upper layers that it can now handle
> the command that it had failed earlier with SCSI_MLQUEUE_DEVICE_BUSY.

In theory, you can call blk_run_queue() from the event handler that sees
the device become ready.  I don't think any driver actually does this,
but I can't see it would cause any problem.

James



^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Drivers: scsi
  2012-10-24 22:25 ` James Bottomley
@ 2012-10-24 22:34   ` KY Srinivasan
  0 siblings, 0 replies; 6+ messages in thread
From: KY Srinivasan @ 2012-10-24 22:34 UTC (permalink / raw)
  To: James Bottomley; +Cc: gregkh, linux-kernel, devel, ohering, hch, linux-scsi

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1286 bytes --]



> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> Sent: Wednesday, October 24, 2012 6:25 PM
> To: KY Srinivasan
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; ohering@suse.com; hch@infradead.org; linux-
> scsi@vger.kernel.org
> Subject: Re: Drivers: scsi
> 
> On Wed, 2012-10-24 at 09:25 -0700, K. Y. Srinivasan wrote:
> > When the low level driver returns SCSI_MLQUEUE_DEVICE_BUSY,
> > how is the command retried; I suspect the retry is done after some delay.
> 
> Delay depends mainly on I/O pressure and the unplug timer in the block
> layer.
> 
> > Is this delay programmable? If the device state changes,
> > can the low level driver notify upper layers that it can now handle
> > the command that it had failed earlier with SCSI_MLQUEUE_DEVICE_BUSY.
> 
> In theory, you can call blk_run_queue() from the event handler that sees
> the device become ready.  I don't think any driver actually does this,
> but I can't see it would cause any problem.

I will try this. Thanks for your prompt response.

Regards,

K. Y
 

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Drivers: scsi
  2012-11-04  9:39 ` James Bottomley
@ 2012-11-04 15:26   ` KY Srinivasan
  0 siblings, 0 replies; 6+ messages in thread
From: KY Srinivasan @ 2012-11-04 15:26 UTC (permalink / raw)
  To: James Bottomley; +Cc: gregkh, linux-kernel, devel, ohering, hch, linux-scsi

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1335 bytes --]



> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> Sent: Sunday, November 04, 2012 4:39 AM
> To: KY Srinivasan
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; ohering@suse.com; hch@infradead.org; linux-
> scsi@vger.kernel.org
> Subject: Re: Drivers: scsi
> 
> On Sat, 2012-11-03 at 09:40 -0700, K. Y. Srinivasan wrote:
> > Do we currently support dynamic re-sizing of LUNs. Hyper-V can
> > notify capacity change via sense data and I was wondering if this
> > is handled in the generic scsi code.
> 
> Depends what you mean by "dynamic".  Experience shows that most users
> really don't want all this to happen without manual intervention
> (particularly on shrink).  However, we have the mechanics in place.
> Just send ASC/Q 2A/09 and it can get vectored up to LVM which resizes
> the volume and can be scripted automatically to resize the filesystem.
> 
> hypervisor people tend to have problems with scripting, so there are
> some hacks that do this outside of the normal event system ... see for
> example virtio_scsi.c

Thanks for the prompt response.

Regards,

K. Y
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Drivers: scsi
  2012-11-03 16:40 K. Y. Srinivasan
@ 2012-11-04  9:39 ` James Bottomley
  2012-11-04 15:26   ` KY Srinivasan
  0 siblings, 1 reply; 6+ messages in thread
From: James Bottomley @ 2012-11-04  9:39 UTC (permalink / raw)
  To: K. Y. Srinivasan; +Cc: gregkh, linux-kernel, devel, ohering, hch, linux-scsi

On Sat, 2012-11-03 at 09:40 -0700, K. Y. Srinivasan wrote:
> Do we currently support dynamic re-sizing of LUNs. Hyper-V can
> notify capacity change via sense data and I was wondering if this
> is handled in the generic scsi code.

Depends what you mean by "dynamic".  Experience shows that most users
really don't want all this to happen without manual intervention
(particularly on shrink).  However, we have the mechanics in place.
Just send ASC/Q 2A/09 and it can get vectored up to LVM which resizes
the volume and can be scripted automatically to resize the filesystem.

hypervisor people tend to have problems with scripting, so there are
some hacks that do this outside of the normal event system ... see for
example virtio_scsi.c

James



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Drivers: scsi
@ 2012-11-03 16:40 K. Y. Srinivasan
  2012-11-04  9:39 ` James Bottomley
  0 siblings, 1 reply; 6+ messages in thread
From: K. Y. Srinivasan @ 2012-11-03 16:40 UTC (permalink / raw)
  To: gregkh, linux-kernel, devel, ohering, jbottomley, hch, linux-scsi

Do we currently support dynamic re-sizing of LUNs. Hyper-V can
notify capacity change via sense data and I was wondering if this
is handled in the generic scsi code.


Regards,

K. Y

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-11-04 15:26 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-24 16:25 Drivers: scsi K. Y. Srinivasan
2012-10-24 22:25 ` James Bottomley
2012-10-24 22:34   ` KY Srinivasan
2012-11-03 16:40 K. Y. Srinivasan
2012-11-04  9:39 ` James Bottomley
2012-11-04 15:26   ` KY Srinivasan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).