Boot Camp Partition gelöscht, Neuanlegen klappt nicht

[Sunwalker]

Erledigt | Boot Camp Partition gelöscht, Neuanlegen klappt nicht

Servus,

ich möchte meine Windows BC Partition vergrößern. Dazu habe ich diese per Winclone auf eine externe Festplatte kopiert und anschließend die Windowspartition per Boot Camp Assistent gelöscht.

Danach wollte ich eine neue, größere Partition mit dem Assistenten anlegen, aber ich bekomme angehängte Fehlermeldung.

Dazu habe ich unter anderem gelesen, dass man große Dateien einfach mal auf ne Externe schieben soll, was ich auch gemacht habe. Ich habe nun 105GB freien Speicher (250GB Festplatte) und möchte eine 40GB Partition erstellen. Trotzdem klappt es noch nicht.

Woran kann es liegen?

Die Festplatte kann nicht partitioniert werden, weil einige Dateien nicht bewegt werden können.

Legen Sie eine Sicherung der Festplatte an und formatieren Sie sie mit dem Festplatten-Dienstprogramm als Einzelvolume mit Mac OS-Extended (Journaled). Stellen Sie anschließend die Informationen von der Sicherung wieder her und starten Sie den Boot Camp-Assistenten erneut.

 

[Sunwalker]

Nun habe ich sogar eine Defragmentierung mit iDefrag durchlaufen lassen. Leider hat es nichts gebracht.

 

[matzzz]

Hast du schon probiert die komplette interne Festplatte zu formatieren?
Also OS X per Festplattendienstprogramm auf die externe Festplatte kopieren, interne Platte formatieren, OS X wieder zurück kopieren und dann versuchen die BC-Partition anzulegen.

Würde ich probieren, vielleicht gibts aber auch einen einfacheren Weg (ich kenn ihn aber nicht )

Gruß
matzzz

 

[Sunwalker]

Danke für die Antwort, es hat sich aber soeben erledigt.

Ich habe alle Programme, die in den Startobjekten standen und mir unnötig erschienen, rausgenommen und neu gestartet. Nun ging die Partitionserstellung endlich durch.

 

[GunBound]

Nun habe ich sogar eine Defragmentierung mit iDefrag durchlaufen lassen.

[highlight]Diesen Schwachsinn von einem Programm bitte sofort in den Trash bewegen![/highlight]

Defragmentierungsprogramme schaden dem Mac OS X nur!

 

[Sunwalker]

In wie fern schadet das Programm?

 

[Rastafari]

In wie fern schadet das Programm?

Es schadet eigentlich nicht, es bringt nur genau den gegenteiligen Effekt von dem, den man sich davon erhofft hat. Das System ist anschliessend gut damit beschäftigt, all die dadurch vorgenommenen Änderungen Datei um Datei wieder rückgängig zu machen.

 

[Snoopy181]

In wie fern schadet das Programm?

Der von Rastafari beschriebene Effekt entsteht dadurch, dass OS X ein eingenes Defrag-Programm immer im Hintergrund laufen hat. Wenn Du nun mit einer anderen Software die Dateien anders ordnest, "denkt" OSX, die wären in der "falschen Reihenfolge"

 

[Sunwalker]

Richtig, es schadet also überhaupt nicht. OS X ordnet mit der Zeit höchstens wieder etwas anders an.

Da ich ein ernstes Problem hatte, war es durchaus legitim, diese Methode zu probieren. Bei einigen hat das Defragmentieren ja in diesem Fall etwas gebracht.

Ich mag es nur nicht, wenn Leute schreiben "Dateien fragmentieren unter OS X nicht" oder "Defragmentierungsprogramme für OS X sind gefährlich". Das stimmt nämlich einfach nicht.

 

[Snoopy181]

Nunja, weißt mit Sicherheit, dass Du die Dateien nicht so stark durcheinander bringst, dass das Defrag-Prog von OS X nicht vielleicht Probleme bei der Neuordnung hat? Und was macht es für einen Sinn, alles durcheinander zu bringen, nur damit es nachher wieder geordnet wird? Es macht einfach keinen Sinn...

 

[Sunwalker]

Könnt ihr mir bitte eine seriöse Quelle nennen, auf der ich nachlesen kann, dass zB iDefrag vollkommen anders anordnet, als es OS X von Haus aus machen würde und daher nach der Defragmentierung alles wieder 'komplett' anders angeordnet werden muss?

Im Normalfall ist ein Defragmentierungsprogramm für OS X (wohl) unnötig, da es nichts mehr oder besser macht, als OS X von Haus aus. Aber bei Problemen, die zB durch fragmentierte Dateien hervorgerufen werden können, sollte man die Möglichkeit eines Zusatzdefragmentierungsprogrammes zumindest in Erwägung ziehen. Wie gesagt, bei anderen trat der Fehler nach einer Defragmentierung mit iDefrag nicht mehr auf.

 

[Rastafari]

Könnt ihr mir bitte eine seriöse Quelle nennen, auf der ich nachlesen kann, dass zB iDefrag vollkommen anders anordnet, als es OS X von Haus aus machen würde

OS X ordnet seine Dateien adaptiv, also intelligent nach der jeweiliger Benutzung.
Ein nur einmalig durchlaufendes Programm kann das überhaupt nicht leisten, so sehr es sich auch darum bemühen mag.

Jetzt hast du's hier gelesen, und behaupte ja nicht, ich wäre nicht "seriös".

 

[Rastafari]

"Defragmentierungsprogramme für OS X sind gefährlich". Das stimmt nämlich einfach nicht.

Korrekt, denn richtig müsste es heissen:
"Defragmentierungstools sind immer gefährlich"

Hast du während des laufenden Vorgangs einen Stromausfall oder 'ne Kernel Panik, dann ... zieh dich warm an.

 

[Sunwalker]

So ist's halt leider immer bei Aussagen zu diesem Thema. Es wird nur wiedergegeben, was irgendwo anders von nem anderen User geschrieben wurde, dem man 'vertraut' (oder noch nicht einmal das ).

Mal zu iDefrag: Mir wurde eine minimale Zahl an fragmentierten Dateien angezeigt. Ca 200 waren es glaube ich. Diese hat das Programm eben versucht aneinander zu hängen, so gut es geht. Dabei wurde mit Nichten die komplette Struktur verändert (man bekommt ja eine Übersicht angezeigt, wie die Dateien ca verteilt sind), daher wird nach einem Durchlauf auch nicht alles durcheinander sein.

Wie gesagt, ich weiß, dass ein extra Defragprogramm für OS X in den meisten Fällen unnötig ist, aber zu behaupten, es wäre schädlich, oder gar, unter OS X würde es gar keine Fragmentierung geben, ist nicht korrekt.

Korrekt, denn richtig müsste es heissen:
"Defragmentierungstools sind immer gefährlich"

Hast du während des laufenden Vorgangs einen Stromausfall oder 'ne Kernel Panik, dann ... zieh dich warm an.

Gut, dass das bei mir noch nie vorgekommen ist .

Aber: Was ist dann? Wieviel Datenverlust ist realistisch? Eine Datei? Eine bestimmte Menge an Daten (zB in MB angegeben)?

 

[Snoopy181]

Hot-File-Clustering etc.

Keine Defragmentierung von Hand notwendig​

Eine Defragmentierung durch den Benutzer kann negative Auswirkungen haben, da manche Methoden das hot file clustering stören. Dann ist der Zugriff auf oft verwendete Daten langsamer.

Defragmentierung unter Mac OS X​

Eine Defragmentierung lohnt sich nicht wirklich. Zwar ist tatsächlich ein Geschwindigkeitszuwachs messbar, jedoch wirkt sich dies bei der Benutztung von Programmen nicht merkbar aus. Dagegen steht ein Risiko (wenn auch klein), durch die Defragmentierung einen Datenverlust zu erleiden.

 

[Sunwalker]

Ich möchte euch übrigens eine kleines, aber feines Programm zu dem Thema empfehlen:

hfsdebug + ShowVolumeFragmentation (ums schön grafisch darstellen zu können - einfach in den gleichen Ordner wie hfsdebug kopieren)

Bei mir sehe ich damit zB sehr schön, dass ich keinen zusammenhängenden freien Speicher größer 1 bzw 2 GB habe. D.h., jede neue Datei >1GB wird zwangsläufig fragmentiert. Und auch von Bereichen zwischen 500MB-1GB habe ich nur 3 zur Zeit (btw war das vor iDefrag auch in dieser Größenordnung ).

Keine Defragmentierung von Hand notwendig​

Defragmentierung unter Mac OS X​

Zu 1) iDefrag fasst den hot file Bereich nicht an.
Zu 2) Naja, keine neuen Infos. Wer wichtige Daten nicht sichert, bevor er solche Eingriffe vornimmt, geht natürlich ein Risiko ein. Aber wie dort schon geschrieben wird, es ist sehr klein.

 

[Rastafari]

Wieviel Datenverlust ist realistisch? Eine Datei? Eine bestimmte Menge an Daten (zB in MB angegeben)?

Das in MB zu messen ist der falsche Denkansatz.
Wenn man das tut, was ein Defrag-Programm tun soll, nämlich den physischen Ablageort von Dateien verändern, dann erfordert das in erster Linie eine Unmenge von schreibenden Zugriffen auf genau zwei "Kern"dateien des HFS+ Systems. Das sind der "Directory B-Tree" sowie seine "Behelfsverlängerung", der sog. "Extents B-Tree".
(Im deutsch lokalisierten Festplattendienstprogramm lesen sich die Namen dieser beiden Dateien als "Katalog" bzw "Zusatzdatei für Dateiaufbau".)

Eines der Hauptziele eines Defrag-Programms ist es, die Einträge aus dem letzteren herauszubekommen (ihn im Optimalfall komplett zu entleeren) und in geordneter Form in den ersten zu integrieren. Gleichzeitig sollen zerstückelt gespeicherte Dateien möglichst zu einem zusammenhängenden Bereich ("extent") zusammengeführt werden, so dass die Gesamtzahl der nötigen Extent-Einträge sinkt. (Bis zu acht solcher Extents pro Datei passen jeweils in den Dateieintrag im D-Baum, was dort überläuft wird im E-Baum abgelegt. Der zusätzliche Zugriff auf den E-Baum kostet Zeit, also sucht man das zu vermeiden.)

Normalerweise sind Schreibzugriffe auf diese beiden Kerndateien kein Problem, das geht sehr schnell und sauber vonstatten. Schwierig wird es, wenn entweder sehr viele dieser Änderungen sehr zeitnah auszuführen sind, oder wenn eine dieser Änderungen bewirkt, dass grosse Teile dieser Baumstruktur komplett umgeschichtet und völlig neu aufgebaut werden müssen. Im "worst case" ist der gesamte Baum neu zu errechnen und danach auch so auf die HD niederzuschreiben. Das kann dann ziemlich viel "Denk"arbeit erfordern und dauert manchmal mehrere Sekunden, in denen jede sonstige Plattenaktivität eingefroren werden muss. (So ein Baum kann schnell auf mehrere hundert MB anwachsen.)

Geht während einer solchen "Generalrevision" etwas schief, hast du zwar genau genommen nur eine einzige kaputte Datei, oder vielleicht auch zwei...
...das dumme ist, dass ausgerechnet diese zwei als zentraler Dreh- und Angelpunkt des gesamten Inhalts des Volumes dienen. Sind die kaputt, ist *alles* futsch.

Und das "Journal", das dich vor Beschädigungen dieser zwei treuen Kameraden beschützen soll, hat leider nur eine begrenzte Kapazität. Da ein zu gross angelegtes Journal sehr viel Leistung fressen würde, hält man es in vernünftiger Grösse für den "normalen" Betrieb. Von dem geradezu gigantischen Ansturm an Änderungsanforderungen, den ein Defrag-Programm zwangsläufig produziert, ist es haushoch überfordert (es "läuft über"). Fällt während der Revision der Strom weg und das Journal hat nicht lückenlos jede Aktion zwischengepuffert, kann beim nächsten Systemstart nichts mehr davon fertiggestellt werden --> "Crash total, aus die Maus."

Vielleicht denkst du über den Einsatz solcher Programme lieber doch noch mal etwas nach...

 

[Rastafari]

sehe ich damit zB sehr schön, dass ich keinen zusammenhängenden freien Speicher größer 1 bzw 2 GB habe. D.h., jede neue Datei >1GB wird zwangsläufig fragmentiert.

Schnurzegal, denn gerade bei Dateien dieser Grössenordnung hat Extent-Fragmentierung überhaupt keinen messbaren, geschweige denn einen spürbaren Effekt.

 

[Sunwalker]

Danke für die Ausführungen.

Allerdings werden die B-Trees bei der On-Line oder Optimize Methode von iDefrag wohl gar nicht berührt. Insofern dürfte die Gefahr, dass nach einem Stromausfall alles weg ist, nicht bestehen, oder?

Ganz davon abgesehen: Wann hat man schon mal einen Stromausfall oä? Wer ganz auf Nummer sicher gehen möchte, kann ja vorher ein Backup machen.

Schnurzegal, denn gerade bei Dateien dieser Grössenordnung hat Extent-Fragmentierung überhaupt keinen messbaren, geschweige denn einen spürbaren Effekt.

Hm, warum willst du nicht verstehen, dass ich die Defragmentierung nicht durchgeführt habe, um irgendwelche Geschwindigkeitsvorteile etc zu erreichen, sondern um meine Boot Camp Partition wieder erstellen zu können?

 

[Rastafari]

Allerdings werden die B-Trees bei der On-Line oder Optimize Methode von iDefrag wohl gar nicht berührt.

Dann verändert sich aber überhaupt nichts auf dem Volume.

Du wervechlest das wohl mit dem "Hotfile B-Tree", der ist was anderes und dient der internen Defrag-Methode von OS X. Dort wird aufgezeichnet, wie "heiss" eine Datei ist (u.a. wie häufig sie benutzt wird). Es gibt auch noch eine ganze Menge mehr solcher "Binärbäume" im System. Das "B-Tree" ist eine sehr allgemeine Bezeichnung für eine grundlegende Methodik in der IT, um Datenbanken für extrem schnellen Zugriff zu organisieren. Auch NTFS oder ReiserFS benutzen sowas.

Wann hat man schon mal einen Stromausfall oä?

Unter Garantie im falschen Moment. (lt. Murphy)

Wer ganz auf Nummer sicher gehen möchte, kann ja vorher ein Backup machen.

Dann kann ich das doch auch gleich aus der TM wieder zurückspielen und auf das Programm gänzlich verzichten. Das geht sogar oft schneller und gibt viel bessere Ergebnisse.
(Weil dabei auch alle anderen Strukturen des Dateisystems "entmistet" werden)

warum willst du nicht verstehen

Ich versteh dich schon. Ich rate ja nur ab davon, dafür Geld hinzulegen; und/oder das zu tun, weil man sich was positives davon erhofft.
Unter Windows bringt das ja auch überhaupt nichts, das ist eine reine Beschäftigungstherapie mit Placebo-Effekt. (Windows-Benutzer sind über alles glücklich, wo man draufklicken kann und wo sich dann irgendwas buntes bewegt. Das gibt ihnen das wohlig warme Gefühl, was unglaublich wichtiges und aufregendes geschafft zu haben. In der Zeit, in der man sich mit sowas abtut, installiert man wenigstens kein Linux...)