Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)

[James Bottomley <James.Bottomley@SteelEye.com>]

On Wed, 2005-09-14 at 00:57 -0400, Sergey Panov wrote: 
> Because set of valid LUN id represented by 8 byte combinations is not
> isomorphic to the set of unsigned int values from 0 to UINT64_MAX. While

The transformation we're using is an isomorphism that happens to have
the important property that single level type 00b LUNs are numerically
equal to the legacy uses of the lun value.

> scsilun_to_int() will convert legal LUN id into some integer, the
> int_to_scsilun() function will not produce legal  LUN id for any
> arbitrary integer lun value. 

No that's what I said.  We limit the integer scanned luns to < 256 and
use representation 00b

> For example, sequential LUN scanning should be stopped at int lun = 255
> because result of converting value 256 by int_to_scsilun() will be
> either illegal(best case) or equivalent to int lun  = 0.

It is.  That's this bit of the code:

@@ -965,6 +964,13 @@ static void scsi_sequential_lun_scan(str
                max_dev_lun = min(8U, max_dev_lun);
 
        /*
+        * regardless of what parameters we derived above, on no
+        * account scan further than SCSI_SCAN_LIMIT_LUNS
+        */
+       if (max_dev_lun > SCSI_SCAN_LIMIT_LUNS + 1)
+               max_dev_lun = SCSI_SCAN_LIMIT_LUNS + 1;
+


> LUN id should be presented to the management layers in a way similar to
> MAC addresses or FC/SAS/... WWN . E.g. the usual LUN 4  on some FC
> device will be identified by something like (in 00b, or "Peripheral
> device addressing"):
> 
> WWPN = 22:00:00:0c:50:05:df:6d
> LUN  = 00:04:00:00:00:00:00:00
> 
> 
> Interestingly enough, the following is also LUN = 4 device, but in a
> different addressing mode (01b, AKA "Logical unit addressing"):
> 
> WWPN = 22:00:00:0c:50:05:df:6d
> LUN  = 40:04:00:00:00:00:00:00

Firstly, those two LUNs are actually not equivalent (according to SAM-3
section 4.9.1) because two luns are defined to be different if expressed
in different representations.

Secondly, The idea of using u64 is that all transports that don't use
hierarchical LUNs can simply copy the number as they do today.  This
idea rests on the assumption that arrays responding to REPORT_LUNS on
these transports always reply with type 00b.  This assumption is
suggested (but not mandated) in SAM. If they violate this assumption,
we'll just reject all the LUNs and I'll get a bug report.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/