Diskussion:GUID Partition Table

Abschnitt GUIDs und deren Zuordnung

Auf was bezieht sich die Tabelle unter der Überschrift "GUIDs und deren Zuordnung".

Ansonsten: Toller Artikel, hoffentlich wird er nicht wegen Irrelevanz gelöscht :-/

Diese GUIDs sind eine Zuordnung zu einem Betriebssystem u.ä., genauso wie der Partitionstyp in einer Partitionstabelle. --Kvedulv 16:02, 6. Nov. 2007 (CET)

Die Frage war wohl so gemeint, dass eine verbindliche Quellenangabe fehlt. Wer definiert die GUIDs, gibt es eine zentrale Registrierungsstelle, und woher bekomme ich die aktuelle Liste? --RolandIllig 12:43, 20. Dez. 2007 (CET)

Es gibt keine zentrale Registrierungsstelle, das ist ja der Gag an GUIDs / UUIDs. Eine aktuelle Liste ist auch schwierig, da ja jeder Hanswurst eigene GUIDs benutzen kann. Du kannst nur die Hersteller, deren Dateisysteme/Partitionstypen du unterstützen willst/musst, abklappern und fragen, ob sie dir ihre benutzten GUIDs sagen. Mag sein, dass es im Internet von Freiwilligen zusammengestellte Listen gibt, aber normativ sind die sicher nicht. --RokerHRO 23:15, 9. Apr. 2008 (CEST)

Treiberfehler?

Zu dem Satz: Leider scheint sich auch das Treiberproblem bei der 2-TB-Grenze bei Festplatten größer 2 TB, wie bereits bei 128 GB, zu wiederholen[1] bei dem Daten in den ersten 2 TB überschrieben werden wenn auf einem Bereich über 2 TB geschrieben wird. Ich finde das etwas verwirrend: ist es wirklich so, dass aktuell beim Schreiben hinter 2 TiB, Daten vor 2 TiB auf einer größeren Partition gelöscht werden? Und auf welchen Betriebssystemen ist dies der Fall? An ein 128-GiB-Treiberproblem kann ich mich nicht erinnern. Die Quellenangabe ist zwar schön, aber da die c't den besagten Artikel nicht im WWW frei veröffentlicht hat und ich keine Ahnung habe, wie ich an die Zeitschrift kommen soll, stehe ich jetzt ziemlich verunsichert da. kann jemand, der die zeitschrift hat, vielleicht etwas mehr dazu sagen? --SvenEric 01:16, 29. Jan. 2009 (CET)

In besagtem Artikel wurde eine 4-Terabyte-Festplatte getestet. Da ist aufgefallen, dass unter bestimmten SATA-Controllern von Intel, AMD und JMicron die Kapazität zu niedrig angegeben wurde (nämlich nur 2 Terabyte). Hatte man die Platte aber schon mit einem besser funktionierenden Controller formatiert, hat Vista die Größe der Partitionstabelle entnommen und damit wieder korrekt angegeben -- und in diesem Fall haben dann die fehlerhaften Treiber nach der 2-Terabyte-Grenze wieder von vorne angefangen. (siehe Ganzzahlüberlauf)Zur 128-Gigabyte-Grenze steht im Artikel nur: Genauso verhielt es sich seinerzeit, als die Festplatten die 128-GByte-Grenze überschritten und alte Treiber die neue Adressierungsart noch nicht beherrschten. --Felino 17:24, 5. Feb. 2009 (CET)

Was ich an anderer Stelle (z.B. engl. Wikipedia) gelesen habe war es sehr wohl möglich schon mit DOS-Partitionen über die 2 TB hinaus zu kommen, wenn nur der erste Sektor noch unterhalb lag. Also kein sogenannter "Wrap-Around" (dt. Umbruch), der natürlich fatal wäre. Mag sein manche Treiber von den Platten oder Controllern hatten da wirklich ein Problem - es gibt da aber wohl einen Stand 1 der GPT-Implementierung unter den diversen Windows-Versionen der wohl echt bei 2 TB ein harte Grenze zog (ohne dass es technisch nötig gewesen wäre) und dann doch so um 2006/7 ein Patch raus kam, mit dem üblichen KB-Prefix und ner 8-stelligen Nummer, der im Betriebssystem alle Weichen auf "GO" stellte um diese Barriere mal wieder hinweg zu räumen. Im übrigen - Microsoft hat die Server-Systeme als erstes dafür flott gemacht weil die natürlich Terabytes als erstes benötigen, und dann die Workstation-Varianten teilweise ebenso. Endanwender/Heimnutzer haben davon bis heute nur ganz indirekt wirklich was gehört oder gar einen Vorteil (das mag sich im Lauf der nächsten Jahre leicht verändern). Im übrigen geht mir der Artikel zu wenig auf die Details der XP-Varianten ein, und insbesondere die x86 (cpu: x86-64/EM64T) aber auch x86 (i386/i586) haben durchaus eine diesbezügliche Support-Historie die erwähnt werden sollte. --Alexander.stohr 16:08, 17. Apr. 2010 (CEST)

Sektor-Größe

In dem Text wird an mehreren Stellen expliziet oder impliziet von 512 Byte großen Sektoren ausgegangen. Dies ist aber nicht zwangsläufig gegeben. Wie verhält sich das ganze den z.B. bei 4kByte großen Sektoren? Hat man dann mehr Partitionseinträge (weil die Tabelle imer noch 32 Sektoren groß ist) oder wird dann die Tabelle kleiner (nur noch 4 Sektoren mit insgesammt 128 Einträgen) oder werden von jedem Sektor nur die ersten 512 Bytes benutzt (was natürlich nicht sehr sinnvoll wäre)? Es müsste klar bschrieben werden wie das GPT-Konzept von unterschiedlichen Sektorgrößen beeinflusst wird. --217.110.99.237 13:53, 27. Mai 2010 (CEST)

Die EFI/UEFI Spezifikation spricht nicht von 32 Sektoren, sondern einer Mindestgrösse von 16 KiB die für Partitionseinträge zu reservieren sei. Bei Datenträgern mit 512er Sektoren ergibt das die besagten 32, bei grösseren entsprechend weniger. Es bleibt in jedem Fall bei mindestens 128 möglichen Einträgen. Nicht zu vernachlässigen: Das sind ausdrücklich nur Mindestwerte, man kann nach Belieben auch mehr Platz und damit auch mehr mögliche Partitionen konfigurieren. (Allerdings sind nicht alle im Umlauf befindlichen Werkzeuge darauf tatsächlich auch vorbereitet.)

(nicht signierter Beitrag von 2.208.95.60 (Diskussion) 16:43, 14. Apr. 2012 (CEST))

GPT-Verwendung win32

Die normalen, abwärtskompatiblen Versionen von Microsoft Windows XP, die noch für die 32 Bit-i386-Architektur entwickelt wurden, können auf einer GPT-Festplatte nur mit Einschränkungen installiert werden. Unter anderem benutzen sie nur den Master Boot Record (MBR), um Partitionierungsdaten zu erhalten. Es stehen so nur maximal drei Partitionen zur Verfügung, da der MBR nicht mehr als vier Einträge zulässt, die erste Partition für die EFI-Firmware reserviert ist und erweiterte Partitionen, die mehrere logische Partitionen enthalten konnten, von GPT nicht mehr unterstützt werden.

Ähm, zuerst wird von "GPT-Verwendung durch Win32" gesprochen, dann aber nur noch von MBR-Verwendung. Wie ist denn nun der Zusammenhang?

Ich dichte mir das mal zusammen: Es gibt auf der Platte den alten MBR, der jetzt kein „protectiv MBR“ mehr ist, sondern (maximal) 4 reale Eintrage (alles "primäre Partitionen") enthält. Diese stimmen auf die exakte Blocknummer mit (gleich vielen) 4 Partitionen überein, die auch in der (nachfolgenden) GPT angelegt sind. Und das Win32-System benutzt die GPT überhaupt nicht, sondern einfach den MBR.

Damit bleibt die GPT also gänzlich unbeachtet, und keiner ihrer Vorteile (z.B. >2TB Platten) kommt zum Tragen. (Bestenfalls die Wiederherstellbarkeit bei futschem MBR mittels Spezialsoftware, welche die GPT tatsächlich verwendet.)

Die Partition für EFI-Firmware ist übrigens unnütz, GPT hat mit EFI grundsätzlich erst mal nichts zu tun (außer, dass es im EFI-Dokument mitbeschrieben ist. (Siehe c't 4/2011 S.170: Linux kann GPT verwenden und davon booten, ganz ohne (U)EFI.))

--arilou 15:43, 9. Feb. 2011 (CET)

Soweit ich weiß, ist es bei Apple-Notebooks so: Mac OS X verwendet nur EFI. Um Windows XP (32-Bit) installieren zu können wird mittels Bootcamp-Assistent die HFS-Partiton (von Mac OS X) im Betrieb verkleinert und danach eine FAT-Partition erstellt (diese kann dann unter Windows als NTFS formatiert werden). Unter Windows XP sieht das dann so aus: Erst eine geschützte EFI-Partition (manche Tools erkennen verstecktes FAT, ist aber EFI), danach die HFS-MAC-Partition, danach eine notwendige Lücke und dann die Windows-Partition. Alles primäre Partitionen. Windows erkennt einen Standard-MBR mit drei primären Partitionen, Mac eine EFI-Platte mit drei identischen EFI-Partitionen. Aber versuch bloß nicht unter Windows die Partitionen im MBR zu verändern, beim nächsten Start wird wieder EFI ausgelesen und alles ist durcheinander! Dann lieber ein Backup von Windows machen, dieses löschen, das ganze unter laufendem Mac OS neu partitionieren und Windows neu installieren. J-g-s 13:44, 14. Dez. 2011 (CET)

Deutsch oder Englisch? Entscheidet euch bitte!

Die Tabellen sind alle in einem merkwürdigen Denglish verfasst, mit Deppenleerzeichen zuhauf, deutscher Großschreibung, größtenteils englischen Wörtern und englischer Grammatik.

Entscheidet euch mal bitte. Wir (die ganze Welt) wissen, dass ihr noch immer zwanghaft meint euch für eure Kultur und Sprache schämen zu müssen, weil sonst wieder ein Extremist von der anderen Seite „Da! Nazis!“ schreien würde. Aber so langsam ist mal gut. (nicht signierter Beitrag von 88.77.134.93 (Diskussion) 09:45, 3. Jan. 2012 (CET))

wofür ist datt

Ich vermisse in dem Artikel Gründe weshalb man nicht beim (alten) MBR bleibt sondern jetzt was neues aus dem Hut zaubert. Ich habe leider nur lückenhaftes (gefährliches) Halbwissen - Ich meine es hängt mit den aktuellen Größen der Festplatten zusammen. Ich glaube mal gelesen zu haben, dass mit dem MBR eine Grenze bei 2 TiB liegt ... wie gesagt gefährliches Halbwissen.
--Zuul (Diskussion) 11:22, 7. Mär. 2012 (CET)

Es werden Blöcke auf der Festplatte adressiert (LBA). Jeder LBA ist 512 Bytes groß.

MBR verwendet 32 Bit für die Adressierung von LBAs, damit gibt's 512 * 2^32 = 2199023255552 Bytes (2 TiB) adressierbaren Speicher; alles, was darüber liegt, kann vom MBR nicht angesprochen werden. Außerdem können im MBR maximal 4 Partitionen erstellt werden.

GPT verwendet 64 Bit, damit können 512 * 2^64 = 9444732965739290427392 Bytes (8589934592 TiB = 8 ZiB) adressiert werden. Mit GPT können 128 Partitionen verwaltet werden.

Gulliveig (Diskussion) 04:21, 18. Mär. 2012 (CET)

Anmerkungen: Mit der C/H/S Adressierung in der Partitionstabelle kann man nur 8 GB adressieren; die erste Erweiterung besteht darin, die C/H/S Adressen auf den Maximalwert zu setzen, um anzudeuten, dass die Partition mindestens so groß ist. Mit LBA und 64 Bit bei GPT kommt man dann auf "richtig große" Werte (siehe oben). Aus Kompatibilität reserviert man mit dem alten MBR eine Pseudopartition, die maximal groß ist ("Protective MBR"), sodass alte Betriebssysteme keinen freien Platz finden können. Es können zwar im MBR nur vier Partitionen gespeichert werden, aber über "erweiterte Partitionen" kann man auch beliebig viele (theoretisch) Partitionen verwalten. Nicht richtig ist, dass man mit GPT (maximal) 128 Partitionen verwaltet werden können. Man kann mit dem Schema (nicht mit jeder beliebigen existierenden Partitionstabelle) beliebig viele Partitionen verwalten. Die empfohlene Mindestgröße ist 16 KB (UEFI Spezifikation 2.4, Seite 107: "A minimum of 16,384 bytes of space must be reserved for the GPT Partition Array.") -- Uhw (Diskussion) 12:36, 2. Dez. 2014 (CET)

Unterstützung in Betriebssystemen

Vorletzter Absatz: "Das Fachmagazin c’t konnte in der Anfangsphase der Einführung während des Tests einer 4 TB großen, mit GPT formatierten Festplatte feststellen, [...] Nach meinem Halbwissen kann man eine Platte nicht mit GPT formatieren, sondern höchstens partitionieren. Haut mich, wenn ich Blödsinn rede. --Timbomat (Diskussion) 19:02, 18. Nov. 2012 (CET)

IMHO ist "Formatieren" das Vorbereiten zur Verwendung (In https://en.wikipedia.org/wiki/Disk_formatting steht: "Disk formatting is the process of preparing a data storage device such as a hard disk drive, solid-state drive, floppy disk or USB flash drive for initial use."). In den Floppy-Urzeiten hieß das dann alles mit 0xE5 überschreiben. In gewissem Sinne könnte man also IMHO von mehreren Ebenen der Formatierung sprechen:

• Partitionierung
• Formatieren einer Partition

Bei einem Software-RAID (z.B. Intel® Rapid-Storage-Technik, IRST) käme dann ganz vorne in der logischen Reihenfolge noch die Formatierung der Platte als RAID-Mitglied.--Uhw (Diskussion) 00:20, 18. Nov. 2018 (CET)

Änderungen von FFrenzel

Die Änderungen von FFrenzel (6.Juli, 5 Änderungen) sind schlicht und einfach absoluter Mist. "GPT" steht ja für "GUID Partition Table", "GPT Partition Table" steht also für "GUID Partition Table Partition Table"? Gleiches gilt für die Übersetzung. "GPT-Partition" wäre dann wieder ein sinnvolles Wort, ist aber nicht gleichbedeutend mit "GUID Partition Table" und gehört deshalb nicht an diese Stelle.

Sehr interessant finde ich auch, dass "GPT-Partitions" (nur) mit Diskpart erstellt werden (können). Ich mache das meistens mit gdisk oder gparted, aber gut zu erfahren, dass ich das immer falsch gemacht habe...

Ich bin neu hier und weiß noch nicht wie das so mit dem Zurücksetzen ist. Muss ich dazu jede Änderung nacheinander rückgängig machen oder gibt es auch die Möglichkeit eine ältere Version einfach wiederherzustellen? --SchrödingersZomb (Diskussion) 01:23, 25. Jul. 2013 (CEST)

Ok, habe das gerade selber rausbekommen mit dem zurücksetzen... --SchrödingersZomb (Diskussion) 01:25, 25. Jul. 2013 (CEST)

Ja, danke, dass dir das aufgefallen ist. Mir ist es schlichtweg entgangen. ‣Andreas•⚖ 16:31, 25. Jul. 2013 (CEST)

Mir ist das wegen Diskpart aufgefallen und dann habe ich halt mal geguckt, seit wann das da so drinn steht... --79.215.159.248 01:05, 26. Jul. 2013 (CEST)

Probleme mit GUID / UUID: Wert oder Darstellung?

Ich habe ein Problem mit den UUIDS bzw. GUIDs für die Partitionstypen: In RFC 4122 (A UUID URN Namespace) steht auf Seite 7 (Layout and Byte Order): "...with each field encoded with the Most Significant Byte first (known as network byte order)...". Interpretiere ich die GUIDs so wie sie von parted-3.2 erzeugt werden gemäß RFC 4122, so kommen nicht die Werte heraus, die in der Tabelle angegeben sind: Für eine "Basic Data Partition" finde ich folgende Byte-Folge:

{0xa2, 0xa0, 0xd0, 0xeb, 0xe5, 0xb9, 0x33, 0x44, 0x87, 0xc0, 0x68, 0xb6, 0xb7, 0x26, 0x99, 0xc7} # Wie wählt man eine nicht-proportionale Schriftart für Computer-Output?

Dekodiert man diese gemäß RFC 4122, so erhalte ich "a2a0d0eb-e5b9-3344-87c0-68b6b72699c7", was wiederum nicht mit den angegebenen GUIDs der Tabelle übereinstimmt, weil dort die Zahlen der GUIDs als "little endian" interpretiert werden.

Betrachtet man in Appendix A ("Sample Implementation") von RFC 4122 die Seite 29 (puid()), so sieht man, daß dort die ersten drei Felder als Zahlen und nicht als Bytefolgen ausgegeben werden (d.h.: die Konvertierung von Big Endian wäre demnach beim Einlesen anzuwenden). Also entweder ist RFC 4122 falsch, oder die Tabelle im Artikel, oder die GUIDs sind doch keine UUIDs gemäß RFC 4122. Klärung erwünscht!

Derzeit bin ich der Meinung, daß die GUIDs so wie oben gezeigt (also als a2a0d0eb-e5b9-3344-87c0-68b6b72699c7", und nicht "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7") dargestellt werden sollten. RFC 4122 sagt außerdem, daß die sedezimalen Ziffern in Kleinbuchstaben dargestellt werden.

-- Uhw (Diskussion) 12:20, 2. Dez. 2014 (CET)

Laut Appendix A der EFI Spezifikation wird z. B. die type guid so in die Tabelle auf der Festplatte geschrieben: Die ersten drei, der durch Bindestrich getrennten, Teile der GUID werden little endian geschrieben, der Rest big endian. Beispiel: ESP-Partition GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B steht so in der Tabelle 28 73 2a c1 1f f8 d2 11 ba 4b 00 a0 c9 3e c9 3b Quelle https://developer.apple.com/library/mac/technotes/tn2166/_index.html (nicht signierter Beitrag von 109.85.30.99 (Diskussion) 00:15, 3. Aug. 2015 (CEST))

Bootcode

Wie auch beim MBR erfährt man hier nicht wirklich etwas zum Bootcode bzw. wie der Bootprozess läuft bzw. definiert ist. (Und das ändert sich auch nicht wenn man UEFI gelesen hat.) -- itu (Disk) 06:55, 28. Mai 2015 (CEST)

Beim Artikel Master Boot Record erfährt man eigentlich schon, wie der Bootprozess abläuft. Das Problem ist, dass es eigentlich ein BIOS+MBR-Bootprozess ist, jedoch nicht zwangsläufig beim BIOS immer so ablaufen muss (kann auch BIOS+Bootsektor, der nicht MBR ist, sein), beim MBR jedoch immer (MBR benötigt ein BIOS oder etwas dazu 100% kompatibles, wie UEFI+CSM). Daher steht es im Artikel zum MBR (und nicht etwa im Artikel zum BIOS).

Bei GPT wird die Sache noch komplizierter, da es eigentlich kein Startprogramm gibt: zumindest nicht bei EFI, Apple-EFI, UEFI und Open Firmware (OLPC XO-1).

Allerdings kann man auch mit einem Startprogramm, z.B. von einem BIOS-basierten PC, von einer GPT-partitionierten Festplatte starten. Dazu braucht man ein Startprogramm, das im Bootsektor des Schutz-MBR sitzt und das im Anschluss einen weiteren Bootloader (wie z.B. GRUB) oder direkt einen Kernel auf einer der GPT-Partitionen startet. Siehe auch Booting from GPT von Rod Smith.

Weil der Startprozess sehr stark von der verwendeten Firmware eines Computers abhängt (BIOS, Open Firmware, EFI), ist es nicht so einfach möglich, den Bootprozess zu beschreiben. Man müsste sehr weit ausholen.

Bei MBR ist das einfacher – der enthält nämlich einen dafür vorgesehenen Bootcode.

GPT hat normalerweise keinen Bootcode. Abgesehen natürlich von dem Fall, dass man mit BIOS+GPT starten will: dann hat der Schutz-MBR den nötigen Bootcode.

Doch halt:

Beziehst du dich auf die auf der EFI Service Partition befindlichen EFI-Binary-Bootloader, so ist dazu anzumerken, dass diese nur in Zusammenarbeit mit dem EFI-NVRAM funktionieren, weil sie dort eingetragen werden müssen. Die Ausnahme ist der Fallback-Bootloader in /boot/bootx64.efi (auf 64-Bit-Systemen) auf der ESP (EFI ServiceSystem Partition).

Was meinst du also genau mit Bootcode?

‣Andreas•⚖ 15:48, 12. Jun. 2015 (CEST)

1 MB-Alignment

Wird von der GPT Specifikation scheinbar verlangt ("GPT specifications that require 1_megabyte/2048_sector disk"[1] ). Umseitig steht noch nichts über Alignment. -- itu (Disk) 04:58, 12. Jun. 2015 (CEST)

Nachdem, was ich darüber gefunden habe, ist GPT nach LBA-Blöcken ausgerichtet. Siehe z.B. Ntfs.com. Jedes andere Alignment ist der physischen Blockgröße eines Speichermediums geschuldet (vermutlich, weil logische LBA-Blockgrößen nicht immer der physischen Größe folgen, etwa bei Advanced Format mit 512-Byte logischen aber 4096-Byte physischen Blöcken). Beispielsweise macht Apple unter OS X standardmäßig ein 4 k-Alignment für Partitionen, siehe TN2166, Abschnitt Partitioning Policy. (Beachte: 4k ist 1 LBA-Block bei 4096-Blockgröße und 8 LBA-Blöcke bei 512-Blockgröße.)

In einer GPT-Spezifikation (oder, was sonst so verfügbar ist) habe ich kein zusätzliches Alignment finden können. Auf der Intel-UEFI-Seite findet sich unter Tools and Utilities ein Download für UEFI Disk Utilities, in dessen Quellcode sich ebenfalls ein Ausrichten nach LBA-Blöcken findet – die darin enthaltene Illustration (ASCII) zeigt 1:1 wie auf der Ntfs.com-Seite bereits illustriert ein Layout nach fortlaufenden LBA-Blocknummern.

Auf Linux.com findet sich Using the New GUID Partition Table in Linux (Goodbye Ancient MBR) vom 25. Juni 2013:

GPT has several advantages over the MBR:

• 64-bit disk pointers allows 2⁶⁴ total sectors, so a hard disk with 512-byte blocks can be as large as 8 zebibytes. With 4096-byte sectors your maximum disk size is really really large

Das legt nahe – …with 512-byte blocks … with 4096-byte sectors … – dass GPT auf unterschieldichen LBA-Blockgrößen genau gleich funktioniert: LBA 0 bis LBA LAST, mit dem GPT-Header jeweils auf LBA 1 und LBA LAST-1.

‣Andreas•⚖ 09:49, 12. Jun. 2015 (CEST)

Niemand hat behauptet, dass kleinräumiges und schlechtes Alignment nicht funktioniert. -- itu (Disk) 11:57, 12. Jun. 2015 (CEST)

Vermutlich ist das der Teil der Spezifikation um den es geht:

„To avoid the need to determine the physical block size and the optimal transfer length granularity, software may align GPT partitions at significantly larger boundaries. For example, assuming logical block 0 is aligned, it may use LBAs that are multiples of 2,048 to align to 1,048,576 byte (1 MiB) boundaries, which supports most common physical block sizes and RAID stripe sizes.“

– UEFI Specification Version 2.5 Seite 120

--F. Saerdna (Diskussion) 14:20, 12. Jun. 2015 (CEST)

Ja, das ist es wohl.

‣Andreas•⚖ 14:57, 12. Jun. 2015 (CEST)

Siehe auch superuser.com: Linux tools that can partition GPT with proper alignment

‣Andreas•⚖ 15:00, 12. Jun. 2015 (CEST)

Danke, F. Saerdna. Das wirft bei mir leider wieder die Frage auf, wie sich may übersetzt: soll oder mehr als sollen? -- itu (Disk) 22:17, 12. Jun. 2015 (CEST)

Kein sollen. May heißt es kann so sein (düfen, können, mögen), muss aber nicht. Und genau das passiert ja auch: jedes Betriebssystem setzt seine eigenen Alignment-Größen fest – hat also unterschiedliche Strategien, mit den verschiedenen Blockgrößen umzugehen. GPT selbst legt das aber nicht fest. Außerdem steht das in der UEFI-Spezifikation, die ja viel mehr als nur den GPT regelt. ‣Andreas•⚖ 23:06, 12. Jun. 2015 (CEST)

Hmm, ich bilde mir ein, dass mir vor einiger Zeit jemand mal bedeutet hat, dass may in ~juristischen Texten mehr als "soll" heißt. Weniger als "soll" würde allerdings wohl kaum Sinn ergeben. -- itu (Disk) 06:05, 13. Jun. 2015 (CEST)

Möglich. Allerdings ist die UEFI-Spezifikation kein juristischer, sondern ein technischer Text.

Abgesehen davon steht dort ja nicht Software may align at a 1 MiB boundary, sondern es steht for example a 1 MiB boundary.

Ab Windows Vista ist die voreingestellte Ausrichtung auf 1 MiB gesetzt. Siehe Disk Partition Alignment Best Practices for SQL Server, Unterpunkt Partition Alignment in Windows Operating Systems: In Windows Vista as well as Windows Server 2008, partition alignment is usually performed by default. The default for disks larger than 4 GB is 1 MB;

Mac OS X macht eine 4 k-Ausrichtung und lässt zwischen den Partitionen immer ein wenig Platz.

Unter Linux gibt es alles mögliche – je nach Distribution und verwendetem Partitionierungsprogramm.

Und viele anderen Betriebssysteme, ältere Betriebssysteme, machen keine Korrektur. Mit Glück partitionieren sie nach LBA-Blocknummern. Allerdings kann man ja immer auch manuell partitionieren, denn man weiß ja hoffentlich, welches Speichermedium welche physische Blockgröße hat.

Die im UEFI-Dokument vorgeschlagene Ausrichtung auf 1 MiB macht heute Sinn, aber mit der weiteren Entwicklung und neuen Speichermedien vielleicht nicht mehr. Dann gibt es vermutlich eine Revision dieses Dokuments, und einen neuen Vorschlag für das Alignment.

Mit GPT hat das aber eigentlich nichts zu tun – auch MBR und andere Partitionstabellen sollte man nach der physischen Blockgröße eines Speichermediums ausrichten. Es ist letztlich Betriebssystemsache und System-Administrator-Sache.

‣Andreas•⚖ 08:15, 13. Jun. 2015 (CEST)

Ich kann Andreas nur zustimmen. May heißt hier nicht mehr als kann. (Auch wenn diese RFC nicht explizit in der Spezifikation erwähnt wird, siehe auch RFC 2119) --F. Saerdna (Diskussion) 13:53, 14. Jun. 2015 (CEST)

Danke! RFC2119 ist sogar im Artikel Request for Comments verlinkt… Man lernt nie aus! ‣Andreas•⚖ 14:14, 14. Jun. 2015 (CEST)

GUIDs (Tabelle)

Ich habe mit dieser Änderung die Tabelle der Partitionstyp-GUIDs überarbeitet. Dazu hätte ich gerne Feedback und Hilfe:

1. Sortierung: die Tabelle ist jetzt alphabetisch sortiert. (Hersteller/System)
2. Einheitlichkeit der Farben. Wir sollten durchwegs mit hintergrundfarbe1 bis 9 formatieren, siehe Hilfe:Farbe.
3. Spalten: Ich habe die Spalte „Betriebssystem“ in „Hersteller“ und „System“ zerlegt
   • Apple z.B. bietet mit Apple TV und OS X zwei unterschiedliche Systeme/Betriebssysteme an. Gerade beim Apple TV ist es schwierig, von einem Betriebssystem zu sprechen, jedoch ist es einfach, das System zu benennen. Daher erscheint es angenehmer, von Apple als Hersteller zu den einzelnen Systemen zu den verwendeten GUIDs zu kommen.
   • In Fällen, wo sich diese Unterteilung nicht machen lässt (Linux, *BSD), habe ich die Zellen zusammengehängt.
4. Zu beachten ist, dass GUIDs grundsätzlich nicht auf die aufgelisteten Systeme beschränkt sind. Man kann jederzeit eine beliebige GUID-Partition erstellen und verwenden (gerade Linux und *BSD ermöglichen, dass beliebige GUIDs dennoch richtig verwendet werden können). GUIDs anderer Systeme können aber auch shr oft systemgerecht auf einem fremden System verwendet werden (z.B. verwendet MacZFS die ZFS-GUID für /usr von Solaris).

Ich persönlich finde die Tabelle mit der Priorisierung der Systeme (Betriebssysteme) als Ausgangspunkt okay. Alternativ könnte man die Partition in den Mittelpunkt stellen, und in einer der hinteren Spalten die Systeme auflisten, die diese Partition verwenden. (Vgl. APM).

Jedenfalls hätte ich gerne Feedback. ‣Andreas•⚖ 15:13, 4. Jul. 2015 (CEST)

Ich habe mir die Freiheit genommen, die Tabelle doch komplett umzukrämpeln. Ich habe die GUID als Ausgangspunkt genommen und die MBR-Typen (hexadezimal) mit einbezogen. Das erscheint mir nicht nur in Anbetracht von Hybrid-MBRs sinnvoll, sondern auch der Tatsache wegen, dass jede GUID-Partitionstabelle per Spezifikation auch eine MBR-Partitionstabelle enthält.

Als Ausgangspunkt habe ich parttypes.cc (Zeilen 66 bis 176) von gptfdisk herangezogen.

‣Andreas•⚖ 21:33, 4. Jul. 2015 (CEST)

Falsche Verwendung des Begriffs "LBA"

LBA bedeutet "Logical block addressing" und bezeichnet eine Adressierungsart für die Datenblöcke eines Datenträgers. Nicht die Blöcke selbst! Die GPT beginnt sich also nicht auf "Logical Block Addressing 1", sondern auf "Block 1", wobei die Blöcke nach LBA nummeriert werden. Hat jemand was dagegen, wenn ich das im Artikel in Ordnung bringe? --RokerHRO (Diskussion) 14:58, 24. Dez. 2018 (CET)

Steht nicht in der Spezifikation auch LBA? Soweit mir bekannt ist LBA-Block 0-⚭ schon eine Art, Blöcke anzuspechen. Der Grund ist, dass ein LBA-Block eine Adresse sein kann, genauso wie ein C/H/S-Wert eine Adresse für einen Block sein kann. Darauf basiert dann die Referenzierung von Blöcken. Genauso wie man kein Short Messaging Service versicken kann, weil ein Service ja grundsätzlich nicht verschickbar ist, man dann aber doch eine SMS schickt.

‣Andreas•⚖ 15:53, 24. Dez. 2018 (CET)

Nun, es heißt ja "logical" Block, der kann sich von der realen Blockschreibweise, wie es der Controller der HW in den Speicher schreibt unterscheiden. Insofern halte ich hier LBA als Bezeichner für die GPT Blöcke schon sinnvoll. --109.192.198.207 08:49, 6. Mai 2020 (CEST)

Wo definiert Microsoft die Attributeinträge?

Im Artikel heißt es "Microsoft definiert folgende Attributeinträge:". Es handelt sich um Bit Angaben, es wird aber nicht gesagt, wo genau die definiert werden. Ist damit gemeint, dass die einzelnen Bit im Bereich der gesamten 128 Byte eines Partitionseintrag geschrieben werden? Also Bit 0, 1 und 2 in den Bereich, wo normalerweise die Partitionstyp-GUID steht, womit diese 3 Bits immer Teil der Partitionstyp-GUID sind. Sowie Bit 60, 62 und 63 in den Bereich im 8. Byte des Partitionstyp-GUID Eintrags? Wenn ja, dann sollte man das im Artikel deutlicher ausformulieren. So wie es jetzt drin steht, kann man nur raten bzw. hier fragen. --109.192.198.207 08:46, 6. Mai 2020 (CEST)

Einleitungs-Fail

„... der ausgehend von Großrechnern etwa seit dem Jahr 2000 das BIOS in PCs ersetzte.“ - dabei ist diese Zeitangabe so falsch oder irreführend wie „Großrechner“ unklar. -- itu (Disk) 20:49, 30. Jun. 2020 (CEST)

EFI: Seit 2001 in Itanium-Rechnern. Entwicklung von EFI seit 1999 oder so. Was sind Itanium-Rechner?

Man kann den Text sicher verbessern. Ich selbst kenne keine Itanium-Rechner "persönlich". ‣Andreas•⚖ 20:56, 30. Jun. 2020 (CEST)

Nachtrag: Itanium: Prozessoren bzw. eine Architektur für den Server-Markt. Eine mögliche Umformulierung wäre also, "Großrechner" durch "Server" zu ersetzen. Oder? ‣Andreas•⚖ 21:03, 30. Jun. 2020 (CEST)

Ende der Partitionstabelle

Ich bastle mir gerade einen Partitionstabellen-"Dechiffrierer". Ich bin fast fertig, frage mich jetzt aber noch: Wie ist vorgesehen den letzten Eintrag der Partitionstabelle festzustellen? -- itu (Disk) 12:14, 3. Apr. 2021 (CEST)

Im Header findet sich an Offset 80 die Nummer der (benutzten) Partitionen. ‣Andreas•⚖ 13:14, 3. Apr. 2021 (CEST)

Okay, der Wert im Header ist wohl nicht die Anzahl der benutzten Partitionen, sondern die Größe der Partitionstabelle selbst (bei GPT sind per Spezifikation mindestens 128 Partitionen möglich). Ich denke, man müsste daher alle Partitionen auslesen und wenn eine davon nicht empty ist, kommt sie in die Liste (bzw. der Zähler für benutzte Partitionen zählt eines hoch). Vielleicht hilft dir das weiter: https://metebalci.com/blog/a-quick-tour-of-guid-partition-table-gpt/

‣Andreas•⚖ 13:27, 3. Apr. 2021 (CEST)

Partitionstyp

Welchen Zweck erfüllt eigentlich der Partitionstyp? - dazu sollte durchaus noch was gesagt werden. -- itu (Disk) 18:03, 18. Apr. 2021 (CEST)

Wie schon vorher bei der MBR-Partitionstabelle: Damit Betriebssysteme und andere Software, die die Partitionstabelle auswerten, z.B. wissen, was "ihre" Partitionen sind, z.B. damit sie die dann booten können. --RokerHRO (Diskussion) 18:09, 20. Apr. 2021 (CEST)

Meine Frage galt unausgesprochen für MBR und GPT - Typen.

Und hmmm... Zwar sind wie die Tabelle umseitig auch zeigt die GUID-typen stärker auf Betriebssysteme fokussiert als noch die MBR-Typen, aber auch hier ist das nicht so rein.

Bei MBR ist ja noch eine grosse Vielfalt an Dateisystemen dabei. Wobei Filesysteme in ihren Partitionen selbst ja nochmal ihre eigenen Identifier haben...

Wäre schon interessant was Quellen hierzu sagen. -- itu (Disk) 21:12, 20. Apr. 2021 (CEST)

Das ist wie bei allen Datentypen: Eine Software muss nur das Konzept können, um interoperabel zu sein. Dabei liest die Software die Tabelle in standardisierter Form, kümmert sich dann aber nur um jene Einträge, mit denen es umgehen kann. Damit lässt sich eine Reihe von Problemen umgehen: so können neuere Betriebssysteme neue Partitionenstypen verwenden, ohne dass gleichzeitig die Gefahr bestünde, dass ältere Software diese Daten zerstört, denn die Software lässt von unbekannten Partitionstypen einfach die Finger. Auch Multi-Boot lässt sich damit viel leichter regeln. Und zu guter letzt kann man – was GPT ja nutzt/bietet – auch festlegen, welche Partition das genau ist (der Zweck, wie z.B. freedesktop.org /home). Damit lassen sich gewisse Automatismen und Interoperabilität herstellen.

Ich glaube nicht, dass es irgendwo definitiv festgelegt ist, was der Partitionstyp darstellen soll. Denn er kann ein Hinweis auf ein Dateisystem sein, das von vielen Systemen gleichermaßen nutzbar ist, aber er kann auch system-spezfisch exklusiv sein. Bei GPT könnte ein Anwender (oder Systemadministrator) sogar seinen eigenen Partitionstyp festlegen (nicht öffentlich), und mit diesen z.B. auf Wechselfestplatten (mit wechselnder Partitionierung) dafür sorgen, dass die Partitionen korrekt eingebunden und/oder verwendet werden. Ähnlich wie z.B. Linux-Swap-Partitionen den gewünschten Nutzungszweck per Partitionstyp festlegen und ein automatisches Verwenden ermöglichen.

‣Andreas•⚖ 19:17, 17. Mai 2021 (CEST)