From: Alex Buell on
On Sat, 2010-07-24 at 09:49 -0400, Valdis.Kletnieks(a)vt.edu wrote:
> On Sat, 24 Jul 2010 13:36:06 BST, Alex Buell said:
>
> > The only thing that would please me no end with newer replacements for
> > BIOS is the ability to have 4k boot sectors. Imagine what we can do with
> > 4k what we can't do with 512 bytes.
>
> Are you saying that 4K sectors have some special nice implications for the boot
> process, or that the boot process is the last major hangup to fully supporting
> a device with 4K sectors, which would give us an 8X boost in capacity on all
> the codepaths that work via sector humbers? I suspect you mean the latter, but
> it's early in the morning still.. ;)

It would be interesting to see how newer BIOSses cope with 4k boot
sectors. I'm sure the latest ATAPI standards do allow 4k boot sectors, I
just want to know how this will be implemented for devices with larger
physical sectors than the more usual 512 byte sectors.

> As a side consideration - moving from 512 to 4K moves the associated limit from
> 2 TiB to 16 TiB. Given the current rate of device density increase, how much
> time will that buy us, and what do we do then?

There are now 3TB devices out there. But noone can boot from 4k devices
yet on existing PC systems.

I'm sure a market to provide 3rd party BIOSes able to do this will
develop shortly. I know of one: coreboot.
--
http://www.munted.org.uk

One very high maintenance cat living here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Greg Freemyer on
On Sat, Jul 24, 2010 at 2:40 PM, Yuhong Bao <yuhongbao_386(a)hotmail.com> wrote:
>
>> However, 2TiB limit is
>> inherent in the BIOS programming interface and currently the only way
>> to overcome it is using a completely different BIOS interface (EFI,
>> that is).
> Nope, look at the Int13 extensions, it already support 64-bit LBA.
>
> Yuhong Bao

64-bit LBA? I assume you meant 48-bit LBA from ATA-7. It will
address up to PBs I believe. (KB, MB, GB, TB, PB, ....)

But I've seen lots of "48-bit LBA" supporting controllers that hit
limits at 500GB, 1TB, etc. and needed new firmware updates.

Secondly, if you look at the table on the right of
http://en.wikipedia.org/wiki/Master_boot_record#Disk_partitioning you
see that the starting sector of a partition is defined with a 32-bit
value.

ie. 2TB with 512 byte sectors.

The normal solution is to move to a GPT which requires EFI if you want
to boot from it.

Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Henrique de Moraes Holschuh on
On Sat, 24 Jul 2010, Greg Freemyer wrote:
> Secondly, if you look at the table on the right of
> http://en.wikipedia.org/wiki/Master_boot_record#Disk_partitioning you
> see that the starting sector of a partition is defined with a 32-bit
> value.
>
> ie. 2TB with 512 byte sectors.
>
> The normal solution is to move to a GPT which requires EFI if you want
> to boot from it.

Can't one have a GPT with a guard boot sector which can read the real
partition table?

I think Tejun must mean some big problem at the BIOS APIs required for the
bootloader. Tejun, what exactly croaks at the 2TB boundary (with 512KiB
sectors)?

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yuhong Bao on

> 64-bit LBA? I assume you meant 48-bit LBA from ATA-7. It will
> address up to PBs I believe. (KB, MB, GB, TB, PB, ....)
Yes, the sector number in Int13 extensions really is 64-bit.
Look at the Ralf Brown Interrupt List, for example.

Yuhong Bao

_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on
Hello,

On 07/25/2010 01:22 AM, Henrique de Moraes Holschuh wrote:
> On Sat, 24 Jul 2010, Greg Freemyer wrote:
>> Secondly, if you look at the table on the right of
>> http://en.wikipedia.org/wiki/Master_boot_record#Disk_partitioning you
>> see that the starting sector of a partition is defined with a 32-bit
>> value.
>>
>> ie. 2TB with 512 byte sectors.
>>
>> The normal solution is to move to a GPT which requires EFI if you want
>> to boot from it.
>
> Can't one have a GPT with a guard boot sector which can read the real
> partition table?

Yeah, parted already does that although there seem to be some bugs and
they sometimes are inconsistent. In principle, BIOSes don't really
care about the partition table (they look at it primarily to figure
out geometry and stuff) and can boot as long as the initial boot
sector is accessible.

> I think Tejun must mean some big problem at the BIOS APIs required for the
> bootloader. Tejun, what exactly croaks at the 2TB boundary (with 512KiB
> sectors)?

The 2TiB limit is coming from BIOS software interrupt for disk access
using 32bit for addressing. If there's 64bit extension to BIOS disk
access, everything should work but still locating boot partition under
2TiB is pretty much required at this point, I think.

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/