Heutzutage denkt man ja, es gaebe keine erreichbaren Grenzen mehr in Sachen Filesystem u.ae. Tja, ich wurde die Tage wieder auf den Boden der Tatsachen zurueckgeholt. Es fing damit an, dass unsere neuen Server endlich kamen. Aus 6 500Gb Platten sollte ein Array gebaut werden. Soweit, so gut. Beim einrichten fragte mich der Raidcontroller hin und wieder nach 2TB Support aber ich ging beim ersten Versuch doch recht schmerzlos ran und machte ein 2.5TB grosses Raid5.
Die CentOS4.5 Installation lief ohne groessere Probleme durch, nachdem ich das Konzept mit den Driverdisks (im grub mit “linux text dd” booten) verstanden habe und einfach das dd.iso von einem USB Stick laden konnte. Auch partitionieren klappte bestens mit dem Diskwizard. Doch dann kam der erste Bootvorgang. Schwarzes Bild, blinkender Cursor. Thats it.
Nach rumfragen und surfen stellte ich dann fest, dass Grub noch keine 2TB grossen Platten(!), also nicht Partionen, unterstuetzt.
Ok, also zweiter Versuch. Ich legte diesmal 2 RaidVolumes an. eine 50Gb fuers System und den Rest, also 2450Gb fuer Virtuzzo. Auch diesmal klappte die Installation erstmal bestens, der Diskwizard liess mich die Partitionen einrichten und formatieren. Auch das booten klappte jetzt.
Doch dann eine Meldung, dass System /vz, die grosse Partition bzw auf der fuers System zweiten Platte waer kaputt. Ich habe das mal uebergangen und /vz aus der fstab genommen, damit ich endlich mal sehen kann, ob der Rechner sauber laeuft.
Spaeter hab ich dann einfach /vz neu formatiert und mit Speedtests angefangen. Hier war ich doch ueberrascht, was moderne Rechner so hinbekommen. Was mit allerdings nicht direkt auffiel war, dass /vz nur 250Gb gross war… Und hier fing der Spass an. Nach etwas Recherche war schnell klar: Linux Kernel ab 2.6 haben die 2Tb begrenzung nicht. Dafuer aber viele der alten Tools drumrum, wie z.B. Grub oder fdisk. Zu allem ueberfluss koennen die derzeitigen Bootloader nur von einem “msdos disk label” booten. Dieses kann aber auch nur max. 2Tb grosse Platten. Schoene Scheisse.
Doch es gibt natuerlich eine Loesung.
Zunaechst muss man sich von fdisk verabschieden, da dieser nur msdos disk labels bzw partition tables kann.
Parted ist hier gefragt. Doch eine Warnung beim rumexperimentieren: Parted schreibt direkt auf Platte, also nicht erst nach dem bei fdisk bekanntem “w”!!
Der obige Schritt 2 RaidVolumes anzulegen war schonmal notwendig, da wie schon bemerkt, Grub nur von msdos labels booten kann, nicht von GPT (GUID Partition Table, nutzt z.b. auch Apple bei IntelMacs)
Also muessen wir nun die zweite RaidVolume zu GPT umbauen, bei mir ist das /dev/sdb. Unmounten nicht vergessen!
Mit
parted /dev/sdb print
bekommen wir raus, wie es um die disk geometry bestellt ist:
Disk geometry for /dev/sdb: 0.000-2336501.250 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 239348.502 primary ext3 boot
Information: Don't forget to update /etc/fstab, if necessary.
Wie hier zu sehen, Disk label type ist noch msdos. Wir merken uns aber schonmal start und endgroesse der “Platte”.
Nun muessen wir (Achtung, Datenverlust ab hier) mit
parted /dev/sdb mklabel gpt
den label type umstellen und mit
parted /dev/sdb mkpart primary 0 2336501
die Partition wieder anlegen. Die Start und Endwerte uebernehmen wir aus der parted /dev/sdb print Ausgabe. Mit selbigem Befehl kann man auch ueberpruefen, ob alles korrekt gelaufen ist. Ab hier kann man wieder wie gewoehnlich ein filesystem anlegen, in meinem Fall mit mkfs.ext3 -m0 /dev/sdb1 -L/vz
Das -m0 verhindert die gewoehnliche 5% root Reservierung, die hier Platzverschwendung waere. Mit -L schreibe ich ein filesystemlabel mit, welches die z.B. CentOS fstab so moechte. Noch eine Warnung: aeltere fdisks luegen auch jetzte noch mit der disk geometry, neuere verweisen sinnvollerweise direkt auf parted. Also auf keinen Fall mehr benutzen.
Viel Spass mit dem >2TB Volume 
