jsync prüft nun Speicherplatz sowie neue Option

Nach langer Zeit gibt es mal wieder kleine News.
jsync prüft nun ob im Ziel genügend Platz vorhanden ist.
Sollte dies nicht der Fall sein, wird die Verarbeitung übersprungen.

Des weiteren bekommen jsync nun die Option useHashing.
Wird diese Option per false deaktiviert, wird nicht mehr der Hash der Datei überprüft.
Somit fällt sehr viel Zeit weg, die zum lesen beider Dateien benötigt wird.
Es wird dann nur noch die Größe sowie das Datum der letzen Modifizierung der Datei geprüft.

Dies ist zwar schneller aber auch unsicherer.
Dies sollte man nur machen wenn man wirklich sicher sein kann, dass die Dateien nicht mit einem Programm o.ä. verändert wurden.

Diese Option nutze ich bei mir auch, da es bis zu 6 Stunden dauern kann, bis ca. 300 GB mit einer externen Festplatte ab geglichen wurden.
Somit kann man sich viel Zeit sparen.

Die aktuelle Version wird morgen dann ins SVN gespielt und kann dort dann bezogen werden.
Die aktuellen Tests laufen sehr gut.
Die aktuelle Laufzeit bei der gleichen Datenmenge beträgt nur noch 50% da nun keine größeren Tests mehr gemacht werden müssen.

jsync auf dem besten Wege zur neuen Version

Nachdem ich nun mehrere Tage und Versuche gebraucht habe, den Verbrauch des Speichers von jsync zu mindern, kann ich mit stolz ein neues Resultat liefern.

Bisher habe ich jsync nur über Rekursion durch die Verzeichnisse laufen lassen.
Der Nachteil dabei ist, dass diese Art der Verarbeitung sehr Speicherlastig ist.
Dies liegt daran, dass ich pro Verzeichnis Ebene eine Liste von Pfaden habe.
Sobald bei der Verarbeitung ein Ordner gefunden wird, wird in diesen gesprungen und wieder eine Liste mit Pfaden erstellt.

Dies habe ich mit einem einfachen Mittel gelöst und damit auch eine neue Option eingeführt.
Die neue Option unter der Sektion options trägt den Namen "useFileListSync".

Dabei wird der Ablauf von jsync im Fundament stark verändert.
Anstelle des Durchlaufs per Rekursion, wird nun eine Datei in einem Temporären Ordner angelegt.
Der Pfad zu dem Ordner ist über die Sektion folders mit dem Schlüssel tmp konfigurierbar.
In diesem Ordner wird dann die Datei mit der Zuordnung von Quelldatei und Zielordner angelegt.
Dabei werden absolute Pfade gespeichert gespeichert.

Damit sich die Threads bei der Arbeit nicht in die Haare kommen, bekommt jede Datei einfach die Thread ID als Namen + .txt.
Die Dateien können in dem aktuellen Zustand noch bearbeitet werden, was aber nicht erlaubt sein soll.
Dies werde ich dann noch anpassen.
Insgesamt liegt der Verbrauch des Speichers von jsync nun bei 160 MB bei 2 Threads die größere Dateien hashen sowie abgleichen oder ggf. neue Dateien kopieren.

Somit ist mein Ziel aber noch nicht ganz erreicht.
Als nächstes würde ich einen Verbrauch von unter 100 MB anpeilen.
Ab dies auch klappt, ist noch abzuwarten.

Ansonsten ist die kommende Version sehr stark optimiert um den Verbrauch stark zu reduzieren.

jsync bekommt neue Option

Nachdem sich die aktuellen Optionen schon als Vorteilhaft erwiesen habe ich eine Option eingebaut, die ich mit der Zeit ausarbeiten werde.
So haben viele Linux Programme einen Parameter -v für verbose.
Damit kann man sich extra Ausgaben geben lassen, damit man Zusatzinformationen erhält.

Als Beispiel bei jsync wäre dies eine Ausgabe beim verarbeiten des aktuellen Verzeichnis oder des aktuellen Ordners.
Dies teste ich gerade über meinen Home-Server.
Dieser enthält dann noch eine größere Sammlung an Freigaben mit Filmen, Musik, virtuellen Maschinen sowie Backups für meine Rechner.

Insgesamt wird dies aber einen Nachteil haben.
Das loggen solcher großen Sammlungen wird die Logfiles entsprechend wachsen lassen.
Deshalb ist dies eine Option die im aktuellen Status eher mit Rückhaltung genutzt werden sollte.

Ansonsten plane ich diese Option noch für erweiterte Informationen.
Die Option trägt dabei den Namen verboseInformations und bekommt auch einen true/false Wert.
Per Default wird dieser false sein, damit er nicht die Logs bei großen Datei Anhäufungen sprengt.

Damit ich aber auch möglich gute Erfahrungen mit jsync machen kann, werde ich in der nächsten Zeit mein Windows 7 für Tests verwenden.

jsync wird speicherschonender

Nachdem ich bei meinen Durchläufen im Schnitt bei rund 400 MB + lag, habe ich mich entschieden den Speicher verbrauch bei jsync etwas zu verringern.
Aktuell habe ich dafür eine Testversion erstellt, die nicht mehr so stark mit File Objekten arbeitet.
Nun basiert die Verarbeitung mehr auf Listen mit den absoluten Pfaden zu den entsprechenden Dateien.

Die File Objekte werden dann immer nur erstellt, wenn diese auch wirklich benötigt werden.
Dies hat sich schon als Vorteilhaft angesehen.
So liegt der Verbrauch bei der gleichen Datenmenge im Schnitt bei rund 100 MB.
Natürlich gibt es durch die Rekursion auch noch einen starken Verbrauch.
Ansonsten arbeite ich auch nicht mehr mit statischen Arrays sondern mit Listen.
Der Vorteil dabei ist, dass ich nach der Abarbeitung eines Pfades, diesen einfach entfernen lassen kann und somit wieder Speicher freigeben kann.

Die nächste Version wird erst in den kommenden Wochen erscheinen, da ich aktuell viel um die Ohren habe und vor Weihnachten noch einige Referate sowie Klausuren habe.

Es gibt im SVN für jsync auch einen aktuellen Branch(0.75) der den letzten Stand enthält.
Diesen zu erstellen hat mir sehr viel Arbeit und nerven gespart, da ein anderer Versuch eher in die Hose ging als ich versuchte von Rekursion auf Iteration durch eine Liste mit Dateien zu gehen.
Dies war noch mehr Speicher intensiv, da ich dort gleich alle Dateien in die Liste gepackt hatte.
So wie es aktuell ist, ist es gut genug.

Windows Aufgabenplanung macht das Leben leichter

Ich habe vor einigen Tagen mal feststellen dürfen, was für eine geniale Aufgabenplanung man bei Windows hat.
Während ich Tasks, unter Unix auch Cronjobs genannt, unter Debian immer per Skript im cron.* Verzeichnis anlegen müsste, kann man mit ein paar einfachen Klicks einige Tasks einrichten.

Da ich immer meine Daten gesichert wissen will, habe ich mir einen einfachen Einzeiler gebastelt, der mit xcopy einfach meine gesamten virtuellen Maschinen auf meinen Samba Server verschiebt.

Der simple Befehlt sieht wie folgt aus.

xcopy "d:\virtual\*.vdi" "\\MIDGARD\vm" /J /Y /R /U

Wie man sieht, kann man mit einem einfachen Wildcard mit der Endung .vdi die VMs für Virtual Box sichern.
Diese werden einfach auf den Server Midgard unter die Freigabe vm geschoben.

Dies dauert auch nicht lange, da es über ein Gigabit Netzwerk doch recht flink geht.
Der Task war mit wenigen Klicks für eine wöchentliche Ausführung für Sonntags um 18:00 Uhr eingerichtet.

Dieser Komfort ist doch was tolles.

Wieder mal News von mir :)

Nach einiger Zeit des Microbloggens über Twitter möchte ich mal wieder einen Eintrag in meinen Blog packen.

Ich habe in letzer Zeit leider wenig Zeit, weshalb ich auch nicht mehr so viel blogge wie früher.
Aktuell konzentriere ich mich wieder mehr auf meine Ausbildung sowie das lernen für selbige.

Ansonsten gibt es auch nicht extrem viel neues.
Ich habe in den letzten Tagen mal wieder an jsync gearbeitet und auch gleich ein Update in das SVN Repository eingespielt.

Leider haben meine Tests auch noch ein paar Schwächen in der aktuellen Architektur gezeigt.
So benötigt jsync aktuell sehr viel Speicher, wenn man eine größere Verzeichnisstruktur synchronisieren will.
Dies liegt leider an der Rekursion die für das durchlaufen der Verzeichnise genutzt wird.
Ebenfalls muss jsync doppelte Arbeit leisten, einmal alle alten Dateien löschen und dann im zweiten Durchlauf die neuen einspielen.

An dem Speicherproblem werde ich aber dringend arbeiten müssen.
Dagegen sollte eine Umstellung von der Rekursiven auf die Iterative Abarbeitung helfen :)
Dies versuche ich gerade in Tests umzusetzen um hoffentlich sehr viel Speicher zu sparen.

Wenn alles gut geht, kann ich somit sehr viel Speicher einsparen womit jsync auch für etwas betagtere Rechner brauchbar wird.

Ansonsten reift es schon sehr gut und hat auch schon einen guten Stand.
Ich muss jsync nur noch beibringen über Netzwerke zuarbeiten.
Somit kann man später auch über das Internet auf einem eigenen Repository arbeiten.

Ich hatte hier an das FTP Protokoll gedacht, was sich dazu gut anbieten könnte.
Ich werde hier aber nicht das Rad neuerfinden.
Hier werde ich wohl auf vorhandene Möglichkeiten setzen.

Mit etwas Glück kann man jsync bald auch über das gute Internet nutzen, was den Nutzen sehr steigern würde :)