Is there any plan to support 64bit lun in mainline?

Is there any plan to support 64bit lun in mainline?

[Wangshen (C)]

Hello everyone,

My name is Wang Shen.
I am developing some scsi devices in Linux needs 64bit lun.
Now I am in trouble in scsi driver programming.

According to SAM-5, a LUN structure is 8 bytes long, but it is only 4 bytes long in kernel.
In another word Linux kernel only supports single level LUN, except conglomerate LUN and Hierarchical LUN.
In my project, we need support all of the LUN structures.

I find an archive mail on Tue, 19 Feb 2013 which discussed "scsi: 64-bit LUN support", but it just a patchset.

Is there any plan to merge this patchset to mainline?
If there is a plan, Which version will support 64bit lun?

Re: Is there any plan to support 64bit lun in mainline?

[Hannes Reinecke]

On 10/12/2013 08:35 AM, Wangshen (C) wrote:
> Hello everyone,
> 
> My name is Wang Shen.
> I am developing some scsi devices in Linux needs 64bit lun.
> Now I am in trouble in scsi driver programming.
> 
> According to SAM-5, a LUN structure is 8 bytes long, but it is only 4 bytes long in kernel.
> In another word Linux kernel only supports single level LUN, except conglomerate LUN and Hierarchical LUN.
> In my project, we need support all of the LUN structures.
> 
> I find an archive mail on Tue, 19 Feb 2013 which discussed "scsi: 64-bit LUN support", but it just a patchset.
> 
> Is there any plan to merge this patchset to mainline?
> If there is a plan, Which version will support 64bit lun?

Yes, there is a plan. Sort of.

I have a patchset (basically an update from the original patches)
sitting here in my private repository.

However, there are two other patchsets pending (EH Deadline and
asynchronous command aborts), both of which have been tested
thoroughly _and_ have acked-by from various other parties.
None of these patchset had received any feedback from James
Bottomley, let alone any indication if or when they'll be merged.

So I stopped sending further patchsets, sensing some communication
breakdown on the line.

I try to excite some response from James B. next week in Edinburgh.
At the very least there'll be other persons with whom I'll be able
to discuss further steps.

And yes, this is slightly irritating.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is there any plan to support 64bit lun in mainline?

[Christoph Hellwig]

On Mon, Oct 14, 2013 at 12:32:22PM +0200, Hannes Reinecke wrote:
> However, there are two other patchsets pending (EH Deadline and
> asynchronous command aborts), both of which have been tested
> thoroughly _and_ have acked-by from various other parties.
> None of these patchset had received any feedback from James
> Bottomley, let alone any indication if or when they'll be merged.
> 
> So I stopped sending further patchsets, sensing some communication
> breakdown on the line.

Maybe we'll need to start a common scsi staging tree for all patches
that have gotten a wide amount of reviews and are interesting to many
parties.  Thay way we have one common set of patches for the
distributions to pull from, and a tree to develop against where
dependencies between the patchsets exist.

Re: Is there any plan to support 64bit lun in mainline?

[Douglas Gilbert]

On 13-10-14 11:29 AM, Christoph Hellwig wrote:
> On Mon, Oct 14, 2013 at 12:32:22PM +0200, Hannes Reinecke wrote:
>> However, there are two other patchsets pending (EH Deadline and
>> asynchronous command aborts), both of which have been tested
>> thoroughly _and_ have acked-by from various other parties.
>> None of these patchset had received any feedback from James
>> Bottomley, let alone any indication if or when they'll be merged.
>>
>> So I stopped sending further patchsets, sensing some communication
>> breakdown on the line.
>
> Maybe we'll need to start a common scsi staging tree for all patches
> that have gotten a wide amount of reviews and are interesting to many
> parties.  Thay way we have one common set of patches for the
> distributions to pull from, and a tree to develop against where
> dependencies between the patchsets exist.

Sounds like a good idea. Like Hannes I have several patches
that haven't been rejected but seem to have been lost in
the process:
   - expand the SG_SCSI_RESET ioctl() to include non reset
     escalating variants
   - permit the sg driver to accept SCSI cdbs greater than
     16 bytes long (bsg already can)

Also I have done some work in sg3_utils to support 64 bit
LUNs in Linux. That work assumes the solution proposed by Hannes.

Doug Gilbert

Re: Is there any plan to support 64bit lun in mainline?

[James Bottomley]

On Mon, 2013-10-14 at 12:32 +0200, Hannes Reinecke wrote:
> On 10/12/2013 08:35 AM, Wangshen (C) wrote:
> > Hello everyone,
> > 
> > My name is Wang Shen.
> > I am developing some scsi devices in Linux needs 64bit lun.
> > Now I am in trouble in scsi driver programming.
> > 
> > According to SAM-5, a LUN structure is 8 bytes long, but it is only 4 bytes long in kernel.
> > In another word Linux kernel only supports single level LUN, except conglomerate LUN and Hierarchical LUN.
> > In my project, we need support all of the LUN structures.
> > 
> > I find an archive mail on Tue, 19 Feb 2013 which discussed "scsi: 64-bit LUN support", but it just a patchset.
> > 
> > Is there any plan to merge this patchset to mainline?
> > If there is a plan, Which version will support 64bit lun?
> 
> Yes, there is a plan. Sort of.
> 
> I have a patchset (basically an update from the original patches)
> sitting here in my private repository.
> 
> However, there are two other patchsets pending (EH Deadline and
> asynchronous command aborts), both of which have been tested
> thoroughly _and_ have acked-by from various other parties.
> None of these patchset had received any feedback from James
> Bottomley, let alone any indication if or when they'll be merged.
> 
> So I stopped sending further patchsets, sensing some communication
> breakdown on the line.

There's no communications breakdown, I've just been very busy.  EH
deadline looks OK, but let me look again to make sure.  Async aborts I'm
not necessarily keen on because I know a lot of devices where aborting
just confuses the firmware more, so I think skipping aborts and moving
to LUN reset might be a better form of acceleration.

James 

> I try to excite some response from James B. next week in Edinburgh.
> At the very least there'll be other persons with whom I'll be able
> to discuss further steps.
> 
> And yes, this is slightly irritating.
> 
> Cheers,
> 
> Hannes

Re: Is there any plan to support 64bit lun in mainline?

[Hannes Reinecke]

On 10/14/2013 08:30 PM, James Bottomley wrote:
> On Mon, 2013-10-14 at 12:32 +0200, Hannes Reinecke wrote:
[ .. ]
>>
>> However, there are two other patchsets pending (EH Deadline and
>> asynchronous command aborts), both of which have been tested
>> thoroughly _and_ have acked-by from various other parties.
>> None of these patchset had received any feedback from James
>> Bottomley, let alone any indication if or when they'll be merged.
>>
>> So I stopped sending further patchsets, sensing some communication
>> breakdown on the line.
> 
> There's no communications breakdown, I've just been very busy.  EH
> deadline looks OK, but let me look again to make sure.  Async aborts I'm
> not necessarily keen on because I know a lot of devices where aborting
> just confuses the firmware more, so I think skipping aborts and moving
> to LUN reset might be a better form of acceleration.
> 

Hmm. I've made exactly the opposite experience with FC devices.
A faulty SFP or wiring might cause the occasional frame drop, which
will be happily corrected with an ABTS.
And HBAs like lpfc or qla2xxx even have a fast command abort built
into the firmware, where the firmware will not even wait for a
command abort to hit the wire but rather just disable the exchange
internally and return.
_Not_ sending an abort but rather escalating directly to LUN reset
will only make matters worse here.
Plus a LUN reset won't be able to fix anything here.

But sure, if there are some devices which are confused by aborts,
sure we should be doing something about it.
Just out of curiosity, which devices are we talking about?

I would very much prefer to have inlined command aborts at least for
FC, as it has proven to be really beneficial there.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is there any plan to support 64bit lun in mainline?

[James Bottomley]

Ok may be brief: on top of cliff with fleeting mobile signal.

Hannes Reinecke <hare@suse.de> wrote:
>On 10/14/2013 08:30 PM, James Bottomley wrote:
>> On Mon, 2013-10-14 at 12:32 +0200, Hannes Reinecke wrote:
>[ .. ]
>>>
>>> However, there are two other patchsets pending (EH Deadline and
>>> asynchronous command aborts), both of which have been tested
>>> thoroughly _and_ have acked-by from various other parties.
>>> None of these patchset had received any feedback from James
>>> Bottomley, let alone any indication if or when they'll be merged.
>>>
>>> So I stopped sending further patchsets, sensing some communication
>>> breakdown on the line.
>> 
>> There's no communications breakdown, I've just been very busy.  EH
>> deadline looks OK, but let me look again to make sure.  Async aborts
>I'm
>> not necessarily keen on because I know a lot of devices where
>aborting
>> just confuses the firmware more, so I think skipping aborts and
>moving
>> to LUN reset might be a better form of acceleration.
>> 
>
>Hmm. I've made exactly the opposite experience with FC devices.
>A faulty SFP or wiring might cause the occasional frame drop, which
>will be happily corrected with an ABTS.
>And HBAs like lpfc or qla2xxx even have a fast command abort built
>into the firmware, where the firmware will not even wait for a
>command abort to hit the wire but rather just disable the exchange
>internally and return.
>_Not_ sending an abort but rather escalating directly to LUN reset
>will only make matters worse here.
>Plus a LUN reset won't be able to fix anything here.

Its mostly for*device* firmware problems. The while problem with our reset escalations is that they don't fit with a transport model. Its a bit accidental that abort works for the fc transport because its designed as a device message.

>But sure, if there are some devices which are confused by aborts,
>sure we should be doing something about it.
>Just out of curiosity, which devices are we talking about?

Lots of older drives. Even some arrays (but also only older ones). For them when they start to timeout they've already begun losing track of commands so aborts make this worse.

>I would very much prefer to have inlined command aborts at least for
>FC, as it has proven to be really beneficial there.

Ok, so how about this. I looked over
The running abort series. It looks fine apart from some coding bits. For the deadline, we can't waste all the deadline with the tiny hammer and then fail to use the bigone. Should have internet on Wednesday will expand then.

James

>Cheers,
>
>Hannes

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Is there any plan to support 64bit lun in mainline?

[Vladislav Bolkhovitin]

Hannes Reinecke, on 10/14/2013 11:01 PM wrote:
> And HBAs like lpfc or qla2xxx even have a fast command abort built
> into the firmware, where the firmware will not even wait for a
> command abort to hit the wire but rather just disable the exchange
> internally and return.

Doing so is asking for data corruption. Aborts intended to cleanup commands on the
target, so they could not anyhow badly interact with future commands. Otherwise it is
possible that an old WRITE command stuck in some deep corner inside the target, be
bypassed by such pseudo-abort and then got released AFTER its LBAs written by newer
data, hence overwrite new data by old data.

Vlad