Drivers: scsi

Drivers: scsi

[K. Y. Srinivasan]

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

Re: Drivers: scsi

[James Bottomley]

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

RE: Drivers: scsi

[KY Srinivasan]

> -----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
 

RE: Drivers: scsi

[KY Srinivasan]

[-- 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¥

Drivers: scsi

[K. Y. Srinivasan]

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

Re: Drivers: scsi

[James Bottomley]

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

Re: Drivers: scsi

[James Bottomley]

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

RE: Drivers: scsi

[KY Srinivasan]

> -----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

RE: Drivers: scsi

[KY Srinivasan]

[-- 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¥