support for drives larger than 2TiB

Colin Ian King colin.king at canonical.com
Wed Jul 28 15:43:38 UTC 2010


On Mon, 2010-07-26 at 08:46 -0400, Peter M. Petrakis wrote:
> 
> On 07/25/2010 09:25 AM, Tim Gardner wrote:
> > Colin,
> >
> > Something we're gonna have to start dealing with pretty soon:
> >
> > http://marc.info/?l=linux-kernel&m=127996556318938&w=2
> >
> > I wonder if there are some tests you can add to the BIOS test tool,
> > e.g., how to test for drives that have non-traditional block sizes,
> 
> READ CAPACITY is your friend,
> http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r22.pdf
> 
> Secton 5.15
> 
> - will definitively tell you how large the disk is
> - the length of a block in # bytes
> 
> $ sudo sg_readcap  /dev/sda
> Read Capacity results:
>     Last logical block address=250069679 (0xee7c2af), Number of blocks=250069680
>     Logical block length=512 bytes
> Hence:
>     Device size: 128035676160 bytes, 122104.3 MiB, 128.04 GB
> 
> > large partition sizes, what boot partitions are useable, etc. Perhaps a
> > part of the test tool will have to run from the grub menu (like memtest).
> 
> This might be out of scope for a bios test tool. The limitation as I understand
> the issue is more due to the partition style than anything else. BIOS has supported
> LBA48 (ATA anyways, this isn't an issue for SCSI if recall correctly) for a long time
> which addresses well more than 2TiB. The issue could use some more exploration
> for certain.

LBA48 gives us 48-bit addressing, so the limit is 144 petabytes.  Older
BIOS may not support this and hence requires an upgrade. After some
poking around, I've not yet seen any way of probing the BIOS to see if
it's LBA48 capable or not. This is a test that I can probably only pull
off in real mode.

The ATA-1 standard of 28 bit LBA limits disks to 128 GiB (≈137.4 GB).
The 2002 ATA-6 standard introduced 48 bit LBA which gives us 144
petabytes of addressing.  So it seems that any recent BIOS that supports
> 137 GB has to be LBA48 compliant.

Colin
> 
> Peter
>   
> > rtg
> 






More information about the kernel-team mailing list