bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Differences in Primary GPT Header


From: Jim Meyering
Subject: Re: Differences in Primary GPT Header
Date: Thu, 18 Feb 2010 14:09:20 +0100

Tobias Arp wrote:

> -----Ursprüngliche Nachricht-----
> Von: Jim Meyering <address@hidden>
> Gesendet: 18.02.2010 09:31:54
> An: Tobias Arp <address@hidden>
> Betreff: Re: Differences in Primary GPT Header
>
>>Tobias Arp wrote:
>>> i am using parted  2.1 aand i have some questions about gpt partitions.
>>> I have created a gpt partion on a harddisk. After creating a ntfs file 
>>> system on this partition i got full access to this drive.
>>> I could read and write successfully on it.
>>> I viewed the primary gpt header on my linux computer and printed it.
>>> Then i put this harddisk on my windows 7 pc. The harddisk is detected 
>>> successfully and i can access all files.
>>> But  after having the drive in my windows computer changes are made to the 
>>> primary gpt header.
>>>
>>> Following values aree changed:
>>>
>>> Offset 0x20 = Backup LBA
>>> Offset 0x30 = Last usable LBA
>>>
>>> Both are decreased for about 30 sectors.
>>> Windows does it.
>>
>>Thanks for the report.
>>
>>> When i look into the documentation of gpt partitions it seems to be right 
>>> what windows has done.
>>
>>Why?
>>
>
> I think Offset 0x30 (Last usable LBA) should be the LBA before the Backup 
> Partition Array and not the Last LBA of the Harddisk.
> Or is this wrong?
>
>>Please provide more information, e.g., the output of this:
>>(assuming your disk is /dev/sda)
>>
>>    # parted -s /dev/sda u s print free
>
> Model: ATA LaCie Biggest Qu (scsi)
> Disk /dev/sdb: 11721081216s
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
>
> Number  Start  End           Size          File system  Name                  
> Flags
>  1      34s    11721081182s  11721081149s  ntfs         Basic data partition
>
>
>>
>>That will tell us the size in sectors of your disk.
>>
>>Then tell us the actual values from your primary table by running this:
>>(again, assuming /dev/sda)
>>
>>    # od -w8 -Ad --skip=$((512+32)) -N24 -td8 /dev/sda
>
> 0000544          11721081215
> 0000552                   34
> 0000560          11721081182
> 0000568

Thanks for the info.
I presume those are the parted-assigned values, because they look
sensible.  Let's label things:

  512+32    11721081215   backup LBA
  512+40             34   first usable LBA
  512+48    11721081182   last usable LBA

The first is fine.  It's the number of the zero-indexed final
sector on the disk, i.e., one less than the size reported above:
  > Disk /dev/sdb: 11721081216s

The 34 is ok, albeit not as well-aligned as some might like.
You might prefer to waste a few sectors to make your partition
better-aligned.  For example, start at sector 64, 128 or even use
1MiB-alignment by starting at sector 2048.

The third number is fine, too.
Given the "backup LBA" number, the last usable sector is simply 33 less
than that, to skip over the 32 sectors worth of PTEs.

> Wje i look into the disk with a disk editor on windows 7 the last
> usable sector is 11721081152...

Above, you mentioned that Windows changed the backup LBA value to
something different.  What was that value?

As I read the standard, it is clear: the backup LBA must refer to the
largest addressable sector on the disk.

If you still think some other values are better, please explain why.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]