FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 09-01-2011, 10:39 AM
Scott Ferguson
 
Default SATA 3TB: unsupported sector size -1548812288.

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.



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). :-)
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,
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).
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.


Cheers

--
"Oh sorry, I was taking life seriously."
— Bill Hicks


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E5F60DD.5070902@gmail.com">http://lists.debian.org/4E5F60DD.5070902@gmail.com
 
Old 09-01-2011, 12:29 PM
Stan Hoeppner
 
Default 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:
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.



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). :-)
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...


--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E5F7AC4.2040901@hardwarefreak.com">http://lists.debian.org/4E5F7AC4.2040901@hardwarefreak.com
 
Old 09-02-2011, 02:33 AM
Scott Ferguson
 
Default 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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E60407C.4010300@gmail.com">http://lists.debian.org/4E60407C.4010300@gmail.com
 

Thread Tools




All times are GMT. The time now is 05:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org