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: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...
I have a 4.8TB RAID device attached to a FC3 system via SCSI.Peter Arremann wrote:
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
standard scsi in itsself has a limit of 2TB (32bit block adressing withIt most certainly is an official standard. It's the READ(16) and WRITE(16)
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....
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.
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...Your RAID should not allow you that or at least warn you if it supportsAIC7xxx chips don't care what the length of the command is. It's up to
the extension (what model is it?) but I know for sure that the adaptec
7xxx chips don't.
the driver. I have no idea whether the Linux aic7xxx driver supports
them.
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@xxxxxxxxxxxxxxxxx Code 610.3 301-286-2239
