600 GB fehlen bei lokalem Datastore

[Wirrkopf]

Ich vermissen ca. 600 GB freien Platz von dem mir unklar ist wo er verschwunden ist. Hier die Geschichte:

Auf einer lokalen 3,6 TB HDD (3726_GB_5T0S) gab es einen 3 TB großen gefüllten Datastore.
Auf einer anderen 3,6 TB HDD (3726_GB_CFZK) gab es einen 3,6 TB großen leeren Datastore.
Beide waren unter Windows Server 2012 eingebunden.

Mittels eine bootbaren Clonezilla ISO wurde die 3 TB Windows Partition auf die 3,6 TB Windows Partition übertragen. (Da find der Kuddelmuddel wohl an)

Die ESXi Partitionen der Quell HDD (3726_GB_5T0S) wurten unter ESXi gelöscht, ein neuer 3,6 GB Datastore wurde angelegt, auf diesem eine virtuelle 3,6 GB HDD eingerichtet die unter Windows Server 2012 eingebunden wurde. Schön leer. Die kopierte Partition ist unter dem selben Server ebenfalls eingebunden.

Erstmal die gute Nachricht: Der Inhalt der 3 TB Partition (U: Backup_alt) ist unter Windows vorhanden und es sieht auch gut aus. Datenzugriff funktioniert. Die Leere Partiton ist ebenfalls zu sehen und funtioniert (S: Backup).

Nun die schlechten Nachrichten: Beim übertragen der Partition sind die 600 GB mehr Platz auf der Ziel HDD verschwunden UND der Zugriff auf die Partiton unter Windows ist nur noch halb so schnell wie auf die leere vHDD.

Anzeigen:



Man sieht das die leere HDD auch leer ist und nur 1,68 GB in Benutzung. Bei der kopierten sind 814,28 GB Frei...

Unter Windows sieht es so aus: Beide Partition gleich groß, nutzen angeblich die 3,6 TB auch aus.



Die leere HDD S: Backup ist leer und kann gefüllt werden:


Bis hierher könnte es noch alles zusammenpassen.

Wäre da nicht die Anzeige der kopierten HDD (U: Backup_alt):



Da sieht Windows weiterhin nur die 3 TB der Quellpartiton.

Wo sind die 600 GB nun hin bzw. wie bekomme ich die wieder??? Unter Windows würde ich eigentlich erwarten das im Partitionsmanager eine 3 TB Partiton und 600 GB freier Platz angezeigt werden und ich die HDD vergrößern kann. Ist aber nicht so.

Weiterhin ist die Geschwindigkeit gravierend unterschiedlich (bei identischer Hardware):

Die leere HDD:


Die kopierte HDD mit Inhalt:


Kann es bei den Geschwindigkeitsunterschieden einfach sein das die Bechmarkdatei bei der leeren ganz innen oder wars aussen? liegt bei dem die HDD am schnellsten ist und bei der Vollen eben da wo es am langsamsten ist?

Beide Effekte eher ein ESXi oder ein Windows Problem? Vielleicht weis ja hier jemand eine Erklärung und noch besser eine Lösung.

Das einfachste die HDD nochmal leermachen, Datastore neu anlegen etc. geht nicht weil ich die Daten brauche.

[~thc]

Mittels eine bootbaren Clonezilla ISO wurde die 3 TB Windows Partition auf die 3,6 TB Windows Partition übertragen. (Da find der Kuddelmuddel wohl an)

Ja - in der Standardvorgabe von Clonezilla wird die Partitionstabelle der Quellplatte 1:1 auf die neue Platte übertragen - sie ist dann natürlich gleich groß und die 600 GB "fehlen". Warum die Datenträgerverwaltung trotzdem eine 3,6 TB große Partition sieht, erklärt das allerdings nicht.

Sind die beiden Platten zufällig WD Reds? (WD40EXXX)? Ist die neue exakt der gleiche Typ wie der alte?

[Dayworker]

Wegen der falschen Datenträgergrösse könnte Clonezilla das Problem sein. Ich meine, daß ich da in der längeren Vergangenheit auch schon mal Diskrepanzen festgestellt hatte.
Das die Platte jetzt so langsam ist, könnte wie ~thc vermutet, entweder an der Platte selber (SMR oder CMR) oder auch an einem fehlerhaften Alignment liegen.

[Wirrkopf]

Sind die beiden Platten zufällig WD Reds? (WD40EXXX)? Ist die neue exakt der gleiche Typ wie der alte?

Ja sind zwei gleiche WD Reds

Die Geschwindigkeit ist jetzt nicht so wild. Reicht wenn selten mal jemand die alten Daten braucht.

Aber die 600 Gb könnte ich schon für was anderes gebrauche....

[Dayworker]

Wirklich 2 gleiche? Ich frage speziell wegen WD-RED EFRX (CMR) oder EFAX (SMR bis 6TB, ab 8TB wieder CMR)...

[JustMe]

Fuer die Geschwindigkeitstests belege doch einfach 3TB auf der momentan noch leeren Windows-Partition S:, und "messe" dann erneut. (fsutil file create new s:\test.dat 3000000000000).
Allerdings bezweifle ich ernsthaft, dass Du mit einer Testdateigroesse von 256MB irgendwas Sinnvolles zusammengemessen bekommst...

PS: Die Begriffe Partition, Datastore, Platte, ... scheinen bei Dir lustig durcheinander zu geraten Vielleicht macht dies es nicht nur mir schwer, Dir zu folgen.

[Wirrkopf]

PS: Die Begriffe Partition, Datastore, Platte, ... scheinen bei Dir lustig durcheinander zu geraten Vielleicht macht dies es nicht nur mir schwer, Dir zu folgen.

Ich hatte gehofft ich hätte mich relativ exakt ausgedrückt. Wo genau habe ich was durcheinandergebracht?

[JustMe]

Naja, Dein vorletzter Thread begann mit den Worten

Ich habe eine 4 TB HDD auf der sich ein 3 TB Datastore befindet bei dem irgenwann mal ein Snapshot angelegt wurde.

, und dazu einem Bild von einer Thin-provisioned (Snapshot-)vmdk.
Aber auch hier im Thread-Opener erwaehnst Du wieder

Auf einer lokalen 3,6 TB HDD (3726_GB_5T0S) gab es einen 3 TB großen gefüllten Datastore.

Dann beschreibst Du die Verwendung von CloneZilla zum Kopieren von "Partitionen", aber stellst nicht klar, wie Du es verwendet hast (z.B. die VM damit gebootet, oder den ESXi-Host, oderoderoder.
Letztlich stellt sich mir die Frage, wenn Du schon zwei physische Festplatten unter ESXi mit VMFS-Datastores versehen hast, auf denen sich dann vmdk-Festplattendateien einer (oder mehrerer) VMs befinden, Du nicht einfach im nativen ESXi mit vmkfstools die mit Snapshot versehene vmdk aus dem einen Datastore in den anderen (auf der anderen physischen Festplatte) wie vor laengerem schon von irix vorgeschlagen geclont hast (dabei waere naemlich der Snapshot brav in die Basisdatei eingearbeitet worden), sondern stattdessen offenbar so Merkwuerdigkeiten wie CloneZilla verwendest, und dabei was auch immer uebertraegst.

Aber selbstverstaendlich ist niemand unfehlbar, auch mir unterlief ein kleiner Fauxpas mit einem ueberzaehligen Leerzeichen. Der korrekte Aufruf lautet

Code: Alles auswählen

fsutil file createnew s:\test.dat 3000000000000

[Dayworker]

Clonezilla kopiert je nach Einstellung dann alle Sektoren 1:1 und bläst damit eine Sparse/Thin-VMDK immer auf ihre konfigurierte, maximale Grösse auf. In einer Win-VM sind dann entweder die VMware-Tools bzw deren VMwareToolboxCmd-Script unter "C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd disk shrink c:\" oder der 2-Satz per "sdelete" und bei abgeschalteter VM dann "vmkfstools -K thin.vmdk" oder "vmkfstools –-punchzero thin.vmdk" auszuführen. Bei Linux-VMs ist es dann ähnlich, weil das Zeroing ebenfalls über die Tools oder zu Fuß erledigt werden kann. Letzeres am einfachsten per "dd if=/dev/zero of=0bits bs=20971520" (beschreibt die eingehängte Partition mit 20MiB-Blöcken komplett voll, Linux sollte mit eienr vollgeschriebenen Partition kurzzeitig klar kommen) gefolgt von einem "sudo rm 0bits" (löscht die Datei "0bits" wieder). Bei abgeschalteter VM ist dann wieder "vmkfstools -K thin.vmdk" oder "vmkfstools –-punchzero thin.vmdk" auszuführen.