Re: [OT] SATA 3TB: unsupported sector size -1548812288.
On 01/09/11 22:29, Stan Hoeppner wrote:
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:
https://bugzilla.redhat.com/show_bug.cgi?id=502944
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.
<snipped>
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.
I'm at a loss to answer/respond to that. Beyond my ken :-/
<snipped>
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.
Your suspicion is correct. (see my previous reference to SCSI 2 and 3
CDB LBA sizes)
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.
Certainly AIX supported partitions larger than 3TB prior to 2009 - but
I'm unsure of how that would impact on i386 based Linux.
<snipped>
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...
I don't know - perhaps if you translate the request into Klingon you'll
get an answer, though I note that the OP is bilingual. ;-p
Cheers
--
"I'm just so sick of airports, sitting on planes on runways and the
planes won't take off.
Every time I read about a hijacking on the news I just think to myself
- just do it - let's see how far you get, I paid and didn't get off the
ground.
I've thought about that too - dreamed of it - putting a gun to the
pilot's head. That would feel so good.
"this is a hijacking"
"where do you want to go - Cuba?"
"No, I want to go where this plane was supposed to be five hours ago"
That's right, I'm hijacking this plane to it's scheduled destination."
— Bill Hicks
Reply to: