Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Warum unter OSX 10.6.. das berechnen der Ordenrgröße ewig dauert?

Warum unter OSX 10.6.. das berechnen der Ordenrgröße ewig dauert?

barbagianni
barbagianni19.07.1215:39
Eine Sache die ich unter anderen nicht verstehe ist warum einen Rechner OSX 10.6. (2x2,4 GHz Quad-Core Intel Xeon und 8 Kerne 8GB Ram) soviel Zeit braucht den Ordnerinhalt zu berechnen.

Ich wollte schnell nachschauen wie Größe einige BackUpsordner von Timemaschine sind.(Sie sind übrigens zwischen 200GB und 400GB)

Kann mir jemand das erklären?



0

Kommentare

bestbernie19.07.1216:55
Bei Timemachine sind Ordner nicht unbedingt gleichzusetzen mit normalen Ordnern und deren Inhalten.
Wie schnell berechnet dein Rechner denn andere ordnergrossen?
0
Ziegl19.07.1217:33
Also bei mir geht das ratzfatz
0
void
void19.07.1217:40
barbagianni
2x2,4 GHz Quad-Core Intel Xeon und 8 Kerne 8GB Ram

DAS sagt rein gar nix aus.

Ordnergröße berechnen heißt rekursiv durch alle Unterordner durchwandern. Siehe http://en.wikipedia.org/wiki/Tree_traversal .

Die Größe eines Ordners mit 10 Filmen kann dir der Finder ohne wahrnehmbare Verzögerung berechnen. Die gleiche Dateigröße verteilt auf 10000 Dateien dauert ein vielfaches. Ich würde mal annehmen, die Berechnungsdauer verhält sich ungefähr linear zur Anzahl der Knoten. Die Teilbäume sind natürlich bedingt parallelisierbar, d.h. mehr Kerne helfen tatsächlich, aber beim Datendurchsatz heutiger CPUs ist der Flaschenhals IO.

Einziger relevanter Performancefaktor ist somit die IO-Geschwindigkeit deiner HDD. Mit ner SSD sollte so etwas viel schneller gehen - und das selbst mit einer Taschenrechner-CPU
„Developer of the Day 11. Februar 2013“
0
barbagianni
barbagianni19.07.1218:03
Ziegl
Also bei mir geht das ratzfatz

Bei mir geht es leider nichts ratzfatz. ,-)
void
...

Falls das hilft, mein Interne zusätzliche FPlatte für TimeMachine

SAMSUNG HD103SJ:
Kapazität: 1 TB
Modell: SAMSUNG HD103SJ
Version: 1AJ10001
Native Command Queuing: Ja
Queue Depth: 32
BSD-Name: disk1
Rotation: 7200
Name des Schachts: Bay 2
Partitionstabellentyp: GPT (GUID-Partitionstabelle)


Sie ist eben eine Platte.

Vielleicht soll ich ene tool finden die die ExterneFestplatte Indixieren kann. Weil die Größe der Ordner, Users, usw. auf die StartHD wird gleich berechnet und gezeigt.
0
ma.19.07.1218:24
Es kommt auch drauf an wie voll die Festplatte ist, da kann sich die Geschwindigkeit auch halbieren ...


Automatische Größenberechnung aktivieren:
Den entsprechenden Ordner öffnen, dann im Finder, Ansicht, Alle Größen berechnen aktivieren.

0
almdudi
almdudi20.07.1219:47
barbagianni
Vielleicht soll ich ene tool finden die die ExterneFestplatte Indixieren kann. Weil die Größe der Ordner, Users, usw. auf die StartHD wird gleich berechnet und gezeigt.
Spotlight zum Beispiel.

0
ExMacRabbitPro20.07.1220:44
Ich verstehe auch nicht warum das noch immer so lange dauert. Rekursiv durch alle Order zu gehen und per File-Info die Dateigrößen addieren - irgendwie kann das im Jahr 2012 nicht mehr die Lösung sein.

BeOS konnte das vor über 10 Jahren schon in Sekundenbruchteilen - egal wie viele Dateien in der Ordner-Hierarchie waren. Die hatten nämlich eine Datenbank zur Verwaltung des Dateisystems. Schade dass Apple in über 10 Jahren OS X Entwicklung sich nicht dazu entscheiden konnte das gleiche zu tun. Obwohl sie, wenn ich mich recht erinnere, vor ein paar Jahren den Entwickler des BeFS mal eingestellt haben.

0
almdudi
almdudi21.07.1203:08
Möglicherweise frisst das ständige Aktualisieren einer Datenbank zu viel Rechenleistung oder ist sonstwie unflexibel. Wie oft schaut man schon nach Ordnergrößen?
Ich denke aber, daß die Hänger sowieso einen anderen Grund haben. Mir ist ab und zu passiert, daß die Berechnung, die ansonsten schon flott ging unter 10.5, manchmal endlos dauerte, unabhängig von der Ordnergröße, manchmal lagen nur eine Handvoll Dateien drin (und weder Prozessor noch RAM waren auch nur annähernd ausgelastet).
0
Tömsken21.07.1204:29
Es liegt an den Hard Links.
Wenn Time Machine ein Backup erstellt, dann werden nur die veränderten bzw. neuen Files kopiert, und die bereits gesicherten verlinkt. Wenn nun die Verzeichnisgröße ermittelt werden soll, dann genügt es nicht – wie im "Normalfall" – die Verzeichnisse in einem Rutsch einzulesen. Stattdessen muss der Finder den Hard Links folgen. Das erfordert viel mehr Positionier- und Leseaufwand für die Festplatte.
0
o.wunder
o.wunder21.07.1207:56
Also gehen wir mal weg von den Ordnergrössen bei TImemachine.

Selbst wenn ich zB die Grösse das Homeverzeichnis von meinem Benutzer wissen will, dauert es einige Minuten das zu berechnen, bei 820 GByte Grösse. SnowLeo und 2x2GHz Core2Duo MacBook, late 2007.

Bei Windows zB steht diese Information sofort zur Verfügung.

Das Problem ist wohl anscheinend, dass es wirklich erst auf Anfrage berechnet wird indem anscheinend alle Ordner und Dateien zusammengerechnet werden. Ein anachronistisches Verfahren.

HFS+ scheint sehr veraltet zu sein. NTFS von Windows scheint da moderner zu sein.

Ich frage mich auch warum zB bei einem Timemachine Backup es so lange dauert festzustellen welche Dateien gesichert werden müssen. Bei Windows NTFS gibt es dafür ein Archiv Bit, da weiss das System sofort was noch nicht im Backup drin ist, bei HFS+ muss anscheinend immer bei jedem Backup der Stand im Backup mit den aktuellen Daten verglichen werden um festzustellen was im Backup fehlt.

Ich habe den Eindruck das Apple bei dem Filesystem eine grosse Flickschusterei veranstaltet hat und sich nicht traut auf eine neue innovative Lösung zu setzen.

Frei nach dem Motto:
Wen interessiert schon ein Filesystem.
0
ExMacRabbitPro21.07.1208:57
almdudi
Möglicherweise frisst das ständige Aktualisieren einer Datenbank zu viel Rechenleistung oder ist sonstwie unflexibel.

BeOS war damals das mit Abstand schnellste OS auf dem Markt. Und das auf der Hardware der Ende 90er. Und durch dynamische Attribute, war das DB basierende Filesystem absolut genial. So etwas habe ich bisher nicht mehr gesehen. Aber das Be Filesystem lebt ja in diversen alternativen Betriebssystemen weiter. Wie z.B Haiku.
0
zod198821.07.1209:12
o.wunder:

Du hast mal wieder wie so oft keine Ahnung.

Seit der Einführung von Spotlight in Tiger gibt es fsevents, das geänderte Verzeichnisse auf der Festplatte markiert und in einer Datenbank aufführt.
Die fragen Spotlight, TimeMachine und andere Dienste ab und wissen sofort, was sie sichern/indizieren/bearbeiten müssen, ohne lange zu suchen.
0
o.wunder
o.wunder21.07.1209:18
zod1988
Und warum dauert das Feststellen was gesichert werden muss so lange? fsevents ist anscheinend kein guter Ersatz für den Einbau entsprechender Attribute direkt in das Filesystem, sondern eine Lösung drum herum "gebastelt" um das Filesystem nicht anfassen zu müssen. Normalerweise müsste eine Sicherung sofort starten können, ohne Vorbereitungen.
0
zod198821.07.1209:25
Es dauert doch überhaupt nicht lange. Das Feststellen, was gesichert werden muss dauert seit Jahr und Tag vielleicht 5 Sekunden.
0
ExMacRabbitPro21.07.1209:46
o.wunder
@@zod1988
Und warum dauert das Feststellen was gesichert werden muss so lange? fsevents ist anscheinend kein guter Ersatz für den Einbau entsprechender Attribute direkt in das Filesystem, sondern eine Lösung drum herum "gebastelt" um das Filesystem nicht anfassen zu müssen. Normalerweise müsste eine Sicherung sofort starten können, ohne Vorbereitungen.

FS Events sind sogar besser als dein olles Archive Bit (übrigens ein MS-DOS Relikt)! Denn bei einem Flag auf Dateiebene musst du nach wie vor das gesamte Dateisystem nach allen Files ohne Archivbit durchsuchen. Während bei den FS Events simpel und elegant eine Liste mit den geänderten Dateien geschrieben wird die beim Backup direkt abgearbeitet werden kann. Daher dauert ein stündlicher TM Lauf i.d.R. nur um die 10 Sekunden.
Ich habe unter Windows, egal mit welcher Backup Software, noch nie eine Delta-Sicherung gemacht die auch nur annähernd so schnell gewesen wäre
0
o.wunder
o.wunder21.07.1210:00
Ich sichere nicht stündlich, sondern nur nach Änderungen die ich an Daten vorgenommen habe durch anstecken eines USB2 Drives. Dabei kommen oft über 1GB zusammen (zB durch iTunes Sync). Und die Vorbereitung des Backup dauert fast so lange wie das Schreiben der Daten. Wie auch immer, fsevents ist sicherlich eine sehr gute Sache. Vielleicht liegt es auch an anderer Stelle das die Vorbereitung des Timemachine Backup so lange dauert. Und ich weiß auch dass das Archiv Bit eine sehr angestaubte Sache ist, da ist die ins Filesystem NTFS implementierte Unterstützung von Änderungssicherungen schon wesentlich moderner und das hat HFS+ auch nicht. Wie auch immer.

Warum dauert die Grössenberechnung von vielen Ordnern und vielen Dateien unter OS X sehr lange und warum steht es unter Windows sofort zur Verfügung?
0
barbagianni
barbagianni21.07.1210:08
Viel davon verstehe ich nicht.... aber die Frage bleibt leider noch immer offen:
Warum dauert so lange einen TimeMachine-Ordner oder zu berechnen?


Ich habe übrigens einen Test gemacht. Auf einer Externe Festplatte, eine WD 1TB, habe ich einen Ordner mit einem Datei 2,4MB – ich sage "M" – kopiert.
Nun auch den Inhalt diesem Ordner zu berechne hat ca. 1 Minute gedauert.
Kurz zu Erinnerung: OSX 10.6.8, 2x2,4 GHz Quad-Core Intel Xeon und 8 Kerne 8GB Ram.


Ist das Normal? Nein, es kann nicht sein. Irgendwas stimmt nicht.

Ich muss aber dazu sagen dass ich die Externefestplatte sowie die Interne zusätzliche Timemachine Festplatte aus der Spotlight ausgeschlossen habe.

0
ela21.07.1212:46
Kurzer Exkurs:
Das Archiv-Bit wird unter Windows schon länger nicht mehr genutzt um heraus zu finden, was noch gesichert werden muss. Dafür gibt es seit NTFS ein Protokoll, dass bei Dateiänderungen geführt wird. Dürfte somit unter OS-X und Windows vom Konzept her sehr ähnlich sein.
Außerdem gibt es unter Windows ein System-Event für Dateiänderungen. Anwendungen können einen "Hook" implementieren, um vom System informiert zu werden, wenn Dateien angelegt, geändert oder gelöscht wurden. Backup-Dienste können dadurch eine eigene Todo-Liste führen. Klappt allerdings nur mit lokalen Dateien, nicht im Netzwerk.
0
barbagianni
barbagianni21.07.1215:05
Zwischenbericht.

Ich habe nun Spotlight auch die Weitere Zwei FP freigegeben zu indixieren.
Die externe Platte, die ich für ein komplettes Backup mit CCC benutze ist folgende.
Für diese FP erhalten ich sehe schnell die Information der Ordnergröße.
Festplattenbeschreibung: WD 1TB
Verbindungs-Bus: FireWire
Schreibstatus: Lesen/Schreiben
Verbindungs-Typ: Extern S.M.A.R.T.-Status: Nicht unterstützt
Verbindungs-ID: 40718665392905557
Partitionstabellen-Schema: GUID-Partitionstabelle


Die Platte die intern via SATA verbunden ist und die ich für TimeMachine Benutze:
Festplattenbeschreibung: SAMSUNG HD103SJ Media
Gesamtkapazität: 1 TB (1.000.204.886.016 Byte)
Verbindungs-Bus: SATA
Schreibstatus: Lesen/Schreiben
Verbindungs-Typ: Intern
S.M.A.R.T.-Status: Überprüft
Verbindungs-ID: "Bay 2"
Partitionstabellen-Schema: GUID-Partitionstabelle

Die SAMSUNG-Festplatt gib mir leider trotz Spotlight-indixierung nach sehr lange Zeit die Informationen bez. Ordnergröße.


Jetzt würde ich als Leihe sagen das Problem liegt bei der Platte.




0
breaker
breaker21.07.1215:12
Das Timemaschine Backup besteht nun mal aus sehr sehr vielen Dateien. Die Gesamtgröße von 100.000 Dateien zu ermitteln dauert halt länger, als von nur 100 Dateien.
0
zod198821.07.1217:56
ela:

Danke für den Hinweis.
Schön, dass o.wunder auch von den Sachen, die er und immer als so toll vorbetet, keine Ahnung hat.
0
o.wunder
o.wunder21.07.1220:19
zod1988
Das macht es leider nicht schneller!
0
barbagianni
barbagianni21.07.1222:11
Ich vermute dass hier wirklich keinen "richtige" Informationen wie die TimeMachine funktioniert hat. ... natürlich ich auch nicht!
Sorry aber nach meiner Logik (die vielleicht nur meine ist ), es kann nicht sein dass ein Betriebssystem im Jahr 2011-2012 soviel ewig Zeit braucht der Inhalt eines 200MB-Ordners, so berechnen.

Was der Finder mir als Ordner zeigt entspricht nicht die reelle Position der Daten, mit würde gerade das Wort "Hardlinks" in einem anderem Beitrag vorgeschlagen.

Ich werde weiter recherchieren und darüber berichten.
0
barbagianni
barbagianni21.07.1222:19
Hier nun die Erklärung dazu:

0
o.wunder
o.wunder22.07.1200:27
Tja also gibt es fsevents Einträge NICHT für Dateien, sondern nur auf Ordner Ebene. OS X muss also kräftig Dateien vergleichen für das Backup.
0
Gammarus_Pulex
Gammarus_Pulex22.07.1201:14
Also meine Erfahrung zeigt, dass nicht nur TimeMachines teilweise sehr lange benötigen, um die Gesamtgröße zu berechnen... auch „Nicht-Backup-Ordner" benötigen hier teilweise ewig lange – klar, wenn ein Ordner groß ist, bremst das – aber für einen 200 GB Ordner teilweise über 20 Minuten?

By the way: Warum kann ich mir von OSX 10.7.4 nicht anzeigen lassen, wie groß mein Programme oder Benutzer Ordner ist??
0
zod198822.07.1207:46
o.wunder:

Sonst wäre das Protokoll ja auch riesig. Nochmal: Das Vergleichen dauert wenige Sekunden. Da gibt es gar kein Grund, rumzupfuschen.
0
o.wunder
o.wunder22.07.1209:23
Ich gebe hier mal einen Link zu HFS+ weiter. Ein sehr interessanter Artikel auf Ars
technica:
[url]arstechnica.com/apple/2011/07/mac-os-x-10-7/12/#hfs-problems[/url]
0
barbagianni
barbagianni22.07.1210:41
Wie kann ich nachschauen war ganz genau Timemachine bei einem Backup macht?

TM kopierte Gestern zB. 100MB Daten einfach so, wie im Screenshot, obwohl ich in der Zeit niX an Rechner gemacht habe.
Das kopieren und aufräumen diesen Daten hat ca. 10 Minuten. Das Problem ist dass die Festplatten andauern arbeiten in Hintergrund.


0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.