[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [parted-devel] [parted 1.8.8] msdos label and file system corruption
Re: [parted-devel] [parted 1.8.8] msdos label and file system corruption issues with > 2TB disk
Fri, 28 Dec 2007 11:57:07 -0600
Thunderbird 22.214.171.124 (X11/20070613)
H. Peter Anvin wrote:
> Michael Reed wrote:
>> Via analysis of the MSDOS partition table, I can state that it can address
>> a maximum of 4TB of space. Each partition entry consists of a starting block
>> and a length. Both of these fields are 32 bits in length. No individual
>> partition can begin beyond 2TB. No individual partition can be longer than
>> 2TB. In order to address 4TB, at least two partition table entries must be
>> used, for example:
> That's a very optimistic view that both depends on optimal layout and no
> 32-bit bugs anywhere.
Linux seems to get it right!
We hand crafted the partition table entries using parted's "unit sector"
input and then used device mapper to concatenate them together. Worked
like a charm.
But, it is still quite optimistic to assume that something won't go haywire
once the user has it. It might be better to limit the partition start
and length entries to no more than 0xfffffffe to avoid conflict with the
GPT PMBR definition of 0xffffffff which represents the entire disk.
> I'm considering adding GPT support to extlinux (syslinux), although it
> is complicated by the fact that there is no standard protocol to support
> booting from GPT partitions on BIOS systems.
What are the various protocols in use for booting from GPT partitions
on BIOS systems? Trying to standardize on one could be a "good thing".
My thoughts immediately come to this as one possibility. Use the GPT PMBR
to define a bootable paritition and reserve the rest of the disk. I know
that isn't the spec, but for linux one could use the "gpt" kernel command
line option to override the test for a valid PMBR. This non-standard usage
of the PMBR is likely only an issue on EFI based systems, and those wouldn't
require the hack....
> I'm thinking of doing
> something like the following:
> DS:SI, which normally points to the partition table entry of the booted
> partition, points to a synthetic MBR partition entry with type 0xEE, and
> if < 2 TB has valid start and length fields; otherwise -1. The GPT
> partition table entry follows the 16 bytes of the synthetic MBR PTE.
> extlinux itself doesn't need any support to handle GPT per se, although
> it won't support /boot extending past the 2 TB boundary any time soon.
I believe it is entirely reasonable to require that /boot be within the
first 2TB of a disk.