-----Ursprüngliche Nachricht----- Von: Jim Meyering <j...@meyering.net> Gesendet: 18.02.2010 14:09:20 An: Tobias Arp <tobias...@web.de> Betreff: Re: Differences in Primary GPT Header
>Tobias Arp wrote: > >> -----Ursprüngliche Nachricht----- >> Von: Jim Meyering <j...@meyering.net> >> Gesendet: 18.02.2010 09:31:54 >> An: Tobias Arp <tobias...@web.de> >> 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/ _______________________________________________ bug-parted mailing list bug-parted@gnu.org http://lists.gnu.org/mailman/listinfo/bug-parted