[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.
>>>
>>>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.
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!
http://produkte.web.de/go/02/