[Top][All Lists]

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

Re: Differences in Primary GPT Header

From: Tobias Arp
Subject: Re: Differences in Primary GPT Header
Date: Thu, 18 Feb 2010 15:47:10 +0100 (CET)

-----Ursprüngliche Nachricht-----
Von: Jim Meyering <address@hidden>
Gesendet: 18.02.2010 14:09:20
An: Tobias Arp <address@hidden>
Betreff: Re: Differences in Primary GPT Header

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

Yes the sectors are right sorry.. i noticed that i have calculated these values 
with the wrong LBA count of the harddisk.
>If you still think some other values are better, please explain why.

Buit its still strange that windows does change some values.
NEU: Mit WEB.DE DSL über 1000,- ¿ sparen!

reply via email to

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