Xen devel - Jul 2008 - [PATCH] pvSCSI: Sanity check for REPORT_LUN emulation

Hi Steven-san and all,

I will attach a patch in order to provide following.

- Sanity check for REPORT_LUN emulation.
- Return "residual" value from backend to frontend. The residual value
  is used to represent difference between request size the frontend
  requested and size backend actually responded.

Best regards,


Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>

-----
Jun Kamada


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> I will attach a patch in order to provide following.
> 
> - Sanity check for REPORT_LUN emulation.
Thank you, that''s much better.

I have one slight issue with the new approach: if a REPORT_LUNS
command races with a LUN hot-add on the backend, you tell the frontend
that the command failed.  Might it be better to instead retry the
command on the backend?

It''s pretty unlikely that anyone would actually hit this race, and the
current behaviour isn''t completely unreasonable, but it seems like
retrying in the backend would be a bit more robust.  What do you
think?

Steven.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Steven-san,

Sorry for delay.

On Fri, 18 Jul 2008 14:58:41 +0100
Steven Smith <steven.smith@citrix.com> wrote:
> > I will attach a patch in order to provide following.
> > 
> > - Sanity check for REPORT_LUN emulation.
> Thank you, that''s much better.
> 
> I have one slight issue with the new approach: if a REPORT_LUNS
> command races with a LUN hot-add on the backend, you tell the frontend
> that the command failed.  Might it be better to instead retry the
> command on the backend?
> 
> It''s pretty unlikely that anyone would actually hit this race, and
the
> current behaviour isn''t completely unreasonable, but it seems like
> retrying in the backend would be a bit more robust.  What do you
> think?
Yes, I consider retrying is a right way, because we can expect few 
times retrying will certainly succeed in this case.
I will attach a patch with the number of retry is three. How do you
think three times retry is appropriate?

Best regards,


-----
Jun Kamada


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Sorry for delay.
Don''t worry about it; I''m just as bad.
> > > I will attach a patch in order to provide following.
> > > 
> > > - Sanity check for REPORT_LUN emulation.
> > Thank you, that''s much better.
> > 
> > I have one slight issue with the new approach: if a REPORT_LUNS
> > command races with a LUN hot-add on the backend, you tell the frontend
> > that the command failed.  Might it be better to instead retry the
> > command on the backend?
> > 
> > It''s pretty unlikely that anyone would actually hit this
race, and the
> > current behaviour isn''t completely unreasonable, but it seems
like
> > retrying in the backend would be a bit more robust.  What do you
> > think?
> Yes, I consider retrying is a right way, because we can expect few 
> times retrying will certainly succeed in this case.
> I will attach a patch with the number of retry is three. How do you
> think three times retry is appropriate?
The patch looks fine.  Three retries sounds pretty reasonable; failing
once is unlikely, so failing four times in a row shouldn''t really
happen unless there''s something else wrong.

(Famous last words :)).

Steven.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel