kernel recognizing large (> 2.1 TB) block devices ?

[Randall A. Jones]

This SCSI card is an Adaptec 39160.
The RAID is a Nexsan ATABoy2 with a SCSI interface.
It seems that the driver recognizes the need and is trying to use the 
READ(16) command but that it is failing.
from log:

sdc : very big device. try to use READ CAPACITY(16).
sdc : READ CAPACITY(16) failed.

I'm assuming the Nexsan device will work correctly given a capable controller and OS/driver.
It has a special mode that allows >2.1TB LUNs to be created.  The default system config only allows for
2199023 MB LUNs (~2.1TB).
Nexsan engineers don't have a firm answer for me on this issue.  They are not aware of any of their customers using a LUN this large on their device but they say it should work given a capable system.

I can put a Fiberchannel controller in the ATABoy2 RAID unit.  Then connect to a Fiberchannel HBA on the server.  Is it possible that there is a capable FC HBA that can do SCSI-3 and 16byte SCSI commands properly to handle the large device?
I have a QLogic 2342 HBA on hand and the specs for the card state that it has "SCSI-3 Fibre Channel Protocol (SCSI-FCP)" "compliance".  Is it possible this will work?

I've heard that LSI might have a similar capability.

Thanks for the info and discussion.

Randall
  


Peter Arremann wrote:

>On Tuesday 11 January 2005 22:17, Eric Smith wrote:
>  
>
>>Randall A. Jones wrote:
>>    
>>
>>>I have a 4.8TB RAID device attached to a FC3 system via SCSI.
>>>The system recognizes a RAID LUN volume of 2.1TB or less without any
>>>problem.  When I configure the RAID as a full 4.8TB LUN, the kernel
>>>fails to recognize its actual size
>>>      
>>>
>>Peter Arremann wrote:
>>    
>>
>>>standard scsi in itsself has a limit of 2TB (32bit block adressing with
>>>512 byte blocks). LSI (others have followed since) has new enhancements
>>>(http://www.infortrend.com/%5CNews%5C20041006%5Cf_64Bit_LBA.htm) but I
>>>know of no storage devices that currently implement that since it is not
>>>an official standard and seems to have some other problems....
>>>      
>>>
>>It most certainly is an official standard.  It's the READ(16) and WRITE(16)
>>commands in SCSI-3, and Google turns up evidence that Linux 2.5.x added
>>support for them in December 2002.  Perhaps that support hasn't been
>>retrofitted to all drivers, or perhaps Randall is encountering a limit
>>somewhere else in the kernel.
>>    
>>
>go to T10.org - the guys that write the scsi standards documents - go to 
>scsi-3 standards documents and then follow the link to any of the scsi-3 docs 
>like sbc... then read the first line and look where the URL takes you - it 
>says DRAFTS... and as such its not an official standard and anyone who has 
>been around long enough will tell you how wonderfully compatible the 
>implemenations of scsi-2 under the first few draft revisions...
>
>
>  
>
>>>Your RAID should not allow you that or at least warn you if it supports
>>>the extension (what model is it?) but I know for sure that the adaptec
>>>7xxx chips don't.
>>>      
>>>
>>AIC7xxx chips don't care what the length of the command is.  It's up to
>>the driver.  I have no idea whether the Linux aic7xxx driver supports
>>them.
>>    
>>
>The chip cares - it is the one to emit the command on the scsi bus. If it has 
>no knowledge of that command, then how will it to that? 
>There are several pieces that need to work together - the linux driver needs 
>to understand 16 byte commands, the firmware on your controller needs to 
>support it and then finally the chip on the controller needs to be able to do 
>it. I had a few discussions with two techs from adaptec that both agreed that 
>up to U2 (29160 and newer) the aic7xxx is not able to do this. Newer models 
>can with firmware and driver updates but Adaptec has not (and more than 
>likely will not in the near term or ever) release firmware updates. The 
>drivers are of course no real issue since linux doesn't use the official 
>adaptec driver set... 
>
>I would love for you to prove me wrong since I have tons of (old and new) 
>adaptec hardware that I would like to use with large arrays but with the 
>answers I got I don't think its going to happen...
>
>Peter.
>
>  
>


-- 
..:.::::
Randall Jones     GST      NASA Goddard Space Flight Center
HPC Visualization Support       http://hpcvis.gsfc.nasa.gov
Scientific Visualization Studio    http://svs.gsfc.nasa.gov
rajones at svs.gsfc.nasa.gov      Code 610.3      301-286-2239