Re: [OT] SATA 3TB: unsupported sector size -1548812288.
On 9/1/2011 5:39 AM, Scott Ferguson wrote:
On 01/09/11 19:40, Stan Hoeppner wrote:
On 8/31/2011 12:54 AM, Scott Ferguson wrote:
NOTE: I got well side-tracked here - I'm don't know whether the OP's
problem is partition table type, sector size (some new drives use large
sectors?) or some other reason.
Yes, quite so. Back on topic, this Red Hat bugzilla entry from May 2009
is informative, also dealing with kernel 2.6.18:
The problem in that case was resolved with a patch that:
"Adds support for 16 byte CDBs to the ibmvscsi driver."
As I already suggested, upgrading the kernel will fix the OP's problem.
I simply can't tell the OP how recent a kernel he needs as I don't know
which SATA driver he's using or in what kernel version that driver was
patched with 16 byte CBDs. Upgrading to 2.6.26, the default Lenny
kernel, would probably do the trick. Any Squeeze (2.6.32) kernel would
definitely not have this problem.
I don't/didn't know what the OP's problem was, and as I don't have a 3TB
drive to test I'm not going to speculate (the OP can Google as well as
I also assumed from his posting history that the OP didn't need me to
tell him about the limitations of partition types - so I 'assumed' it
was either a software issue related to handling a disk that size
(filesystem bug), or an issue related to the large sector sizes of some
of the new, very large, SATA drives.
I suspect you are correct about later kernels - I also wonder what
limitations are specific to the i386/amd64 architecture.
The RedHat problem is interesting - though I'm not certain of it's
relevance (which doesn't mean there aren't other, more relevant,
It seems that the code causing the problem doesn't appear to be in the
shared SCSI code, but in the block device driver. In that bug report it
is the IBM virtual SCSI driver, which is apparently specific to the AIX
LPAR environment, similar to the VMware ESX Linux virtual SCSI driver.
I inferred from this that the necessary 16 byte CBD patch would need to
be added to each and every Linux block device driver in a similar
fashion. I am *not* a kernel dev, nor a C programmer--simply doing some
deductive reasoning. I could be all wet.
problems). It's a 10TB partition in question - until *that* patch 12
byte CBDs were possible (6, 10, or, 12) - without digging up the CBD
format I'd hazard a guess that 12 bytes would put the LBA limit around
2TB. These days the CBD size can be variable.
What's particularly interesting about that bug report is the date (2009)
- I certainly was working with partitions larger than 2TB in 2006/7,
which is some years before that bugreport (could be senility on my part).
If my suspicion is correct, some block device drivers could/would very
well have already had 16 byte CDBs long before this 2009 bug report
against this specific IBM driver. If your 10TB LUN was on a Qlogic or
Emulex FC HBA, I'd bet they already had 16 byte CDB support in those
drivers, at that time. It would be silly not to, given the potential
size of SAN LUNs, even going back before 2006. That said, it seems odd
the IBM vscsi driver was limited to 12 bytes. Maybe just an IBM
oversight? I've never used LPAR (or AIX) so I have no idea what IBM's
"best practices" are regarding use of that virtual driver. Maybe it's
only meant to be used for carved up DASD drives in the local chassis,
and a different driver is used for SAN LUNs, or something goofy like
that. Just a stab in the dark.
NOTE: SCSI-3 was around in 2000 - and it's predecessor SCSI-2 supported
32 byte XOR commands... maybe a dig for SAM-2 specs would yield more. I
also have a vague memory that bootablility further restricted the size
of a partition somehow.
I'm thinking in this case that the OP simply has a SATA HBA or mobo down
SATA controller whose mainline Linux driver is limited to 12 byte CDBs
in kernel 2.6.18.
Like I said I could be all wet. This is just the way it looks to me at
this point. It sure would be nice if the OP would reply with his SATA
chip/card model# or that he upgraded his kernel with result X. All we
can do moving forward is guess. He may have already fixed it and we
just haven't been informed...