jsync, nio und der Speicherverbrauch

Gestern habe ich mal einen Test gemacht, der mich doch sehr überrascht hat.
So hat sich die Implementierung zum Dateien kopieren ohne nio als Speicher schonender und effizienter herausgestellt.

Grund für die Umstellung war, dass mir die Tools top und htop unter Debian Lenny immer zeigten, dass der Speicher immer im Gigabyte Bereich gefüllt ist sobald größere Dateien kopiert werden.

Legt man nun aber eine Speichergrenze von 1 MB in der jsync.conf und stellt nio ab, kommt man nur auf 1 MB Speicherverbrauch zusätzlich zu den intern gespeicherten Pfaden.
Bei einer Kopieraktion lag ich im Schnitt bei 100 MB.

Deshalb empfehle ich, auch wenn nio in Java 7 eine wichtigere Rolle spielen wird als die alten io Schnittstellen, eher auf die klassische Art zu setzen, wenn man Speicher schonen will.

Von apt-mirror zu debmirror

Ich mache gerade eine Umstellung von apt-mirror zu debmirror um den main Zweig von Debian stable und testing zu spiegeln.
Grund dafür ist, dass apt-mirror einen seit mehr als 1 Jahr unbehandelten Bug besitzt.
Ebenfalls scheint sich in Sachen apt-mirror in der Entwicklung nichts mehr zu tun.

Deshalb habe ich Gestern mal debmirror isntalliert und bin sehr zufrieden damit.
Das Programm wird nur mit Parametern aufgerufen, weshalb eine statische Konfigurationsdatei komplett entfällt.
Leider muss ich mir durch diese Umstellung das gesamte main Archiv für stable und testing erneut ziehen.

Da debmirror aber weiterentwickelt wird und wirklich mit einfachen Parametern konfiguriert wird, ist die Einstellung recht simpel.

Man benötigt für die Spiegelung wirklich nur ein Skript mit dem Aufruf von debmirror und den Parametern.

Einige gute Anleitungen gibt es hier:
http://wiki.debianforum.de/debmirror
http://www.lug-wr.de/wiki/index.php/Debmirror

jsync, GPL und der erste Release

Gestern hat sich ein Sourceforge Benutzer bei mir nach den aktuellen jsync Dateien informiert.

Leider musste ich diesem sagen, dass es aktuell noch keinen Release gab.
Ich habe mir dies aber auch zu Herzen genommen und habe mich heute um die letzten Probleme in der aktuellen Version gekümmert.

Dazu zählt eine Anpassung zum Validieren der jsync.conf, Einbau des GPL Hinweis in den Kopf einer jeden Code Datei, Anpassungen der aktuellen Dokumentation und und und.

Ich habe auch einen positiven Kommentar auf sourceforge bekommen.
Dort hat sich ein Mac User bedankt und mir mitgeteilt, dass er mit jsync seine Dokumente mit seinem PC synchronisiert.

Es ist schon sehr cool wenn man solche Kommentare lesen kann :)

Google wird zum Provider

Wie ich gerade gelesen habe, will Google in Amerika zum Internet Provider werden.
Das ganze wird erst einmal als Versuch ablaufen.
Dabei sollen Anbindungen von 1GBit/s drin sein.

Man versucht dabei 50.000 bis 500.000 Haushalte anzubinden.
Ich wäre froh wenn ich solch ein Experiment mitmachen dürft.

Ich stelle mir nur die Frage wozu man eine 1GBit/s Leitung benötigt.
Damit kann man schon Dateien in einer extremen Größenordnung verteilen und dies über einen schnellen Ablauf.

Für Torrents wäre es mal eine angenehme Geschwindigkeit.
Aber für den privaten Surfer sehe ich keinen Sinn in dieser Größenordnung.

jsync beherrscht nun symbolische Links

Ich habe bei mehren Tests in der Vergangenheit immer das Problem gehabt, dass jsync nicht mit einem Link angesprochen werden konnte.

Hierbei war das Problem, dass doe jsync.conf immer direkt neben der jsync.jar liegen muss.
Der Pfad zu dieser Datei war bisher immer relativ.
Wenn man nun aber einen symbolischen Link als Verweis nutzt, dann wird versucht in dem Verzeichnis des Links nach der jsync.conf zu suchen.

Dieses Problem lässt sich auch leider nicht wie in C# mit einer Klasse einfach lösen.
Das Problem habe ich so gelöst, dass ich mit die Url für die ConfigHelper.class aus der jar Datei habe geben lassen.

Das Format ist dann file://D:/jsync/jsync.jar!/jsync/helpers/ConfigHelper.class

Somit musste ich nur die URL um file:// kürzen und den Pfad von jsync.jar nehmen um dem absoluten Pfad zu ermitteln.

Dies ist etwas trickie aber funktioniert ohne Probleme.
Im Code liegt auch ein Fix für Entwickler vor.
Den in einer Entwicklungsumgebung hat man keine fertige .jar Datei.

Ansonsten bin ich froh, dass dieses Problem endlich gelöst ist.
Somit kann ich endlich meine ganzen Backup Skripte anpassen.
Es ist ziemlich nervig immer wieder per cd in das Verzeichnis von jsync zu wechseln.

Große Architektur Änderung bei jsync

Ich habe Gestern eine neue Architektur bei jsync eingeführt.
Diese soll lediglich die jFileLib erweitern.

So gibt es nun die Klassen File, Directory und Path.
Diese dienen um Attribute von Dateien zu prüfen.
Path dient hierbei als eine sehr gute Helferklasse zum überprüfen ob es sich um eine Datei oder ein Verzeichnis handelt.

Somit kann man dann über die File oder Directory Klassen dann spezifische abfragen machen.

Des weiteren lagere ich auch viele Teile zum kopieren von Binärdateien aus.
So gibt es wieder das File, FileReader und FileWriter Konstrukt.
Somit kann ein eigenes File Objekt mit einem Reader und Writer als Eigenschaften erzeugt werden um die Operationen beim Lesen und Schreiben von Dateien zu vereinfachen.

Ich finde es leider sehr bedauerlich, dass Java nicht wie C# statische Methoden in der File Klasse bietet.
In Java muss immer ein Objekt erzeugt werden und dann kann erst gearbeitet werden.
Dies hat sich in den ersten Versionen von jsync als sehr Speicherraubend erwiesen.

Diese Architekturumstellung spart nochmals 10 Megabyte RAM bei der Ausführung ein.
Ich werde schauen, ob ich dies nicht noch mehr optimieren kann.

Netbeans ist aus Debian testing geflogen

Ich habe mich vor einiger Zeit mal wieder über die Paketsuche von Debian über Netbeans informiert.

Leider ist es zu etwas gekommen, was ich nicht erwartet hätte.
Da Netbeans in contrib einige .jars enthält die ohne Source Code geliefert werden, ist Netbeans nun aus testing ausgeschieden.

An sich ist dies leider sehr schade, da Netbeans auch in non-free hätte verschoben werden können.
Ich finde es aber auch recht schade, dass es nicht öffentlich bekannt gegeben wurde.
Den Netbeans ist genauso wie Eclipse eine große und anerkannte Entwicklungsumgebung.

Ich werde versuchen mal mit dem Maintainer zu sprechen.
Den obwohl es bereits Netbeans 6.8 gibt, ist in allen Repositories immer noch die uralte Version 6.0.1 aus debian Etch, was eigentlich unbegreiflich ist.

Hat den keiner Lust Netbeans zu maintainen?
Dabei ist diese IDE unter Entwicklern sehr beliebt.

jsync und der Arbeitsspeicher

Ich habe in den letzten Zeiten etwas recht positives festgestellt.

Trotz der Arbeit mit Dateien im Gigabyte Bereich läuft jsync immer mit der gleichen Anzahl an MB im RAM.
Aktuell verbrauch jsync bei einer Synchronisation mit 10 Threads und somit auch mit 10 Synchronisationen gleichzeitig, mit 100-120 MB RAM.

Dies wird manche natürlich doch etwas erschrecken.
Den so manches native C oder C++ Programm bräuchte für so etwas um die 20-30 MB.
Dies liegt an der Architektur von jsync.

Aktuell verwaltet jsync jede Ebene der Verzechnisse über interne Liste.
Diese enhalten dann die Dateipfade in einem Verzeichnis.
Dies wird mit absoluten Pfaden geregelt.

Dies ist bei vielen Dateien nicht gerade wenig Speicher.
Damit der Speicher aber nicht unnötig belegt bleibt, werden die abgearbeiteten Einträge aus der internen Liste entfernt, was wieder viel Speicher frei gibt.

Ich suche aber immer noch einen Weg, damit ich unter die 100 MB Ram bei jsync komme.
Die Möglichkeit mit einer Datei war mal ein guter Anfang aber erwies sich leider als Sackgasse.

Falls jemand eine gute Idee hat, ich höre immer gerne zu :)

Flaschenhals bei jsync.

Ich habe, wie bereits geschreiben, meine gesammte Platte gelöscht und bin dabei diese neu zu befüllen.

Bei einer USB 2.0 Platte ist dies leider alles andere als schön.
Aktuell sitzt in dem Home Server eine Western Digital Caviar Green mit 1 TB Speicher.
Leider ist dort die Schreib- und Lesegeschwingkeit sehr gering.

Grund dafür ist die geringe Umdrehungszahl.
Mit 5400 Umdrehungen ist dies leider sehr lahm aber dafür auch mit geringem Energie verbrauch.

Nun wird die verbaute Platte leider so stark belastet, dass es fast schon einem alten Prozessor mit 200 Mhz gleichkommt, wenn man an dem System arbeiten will.

Ich habe deshalb werde ich wohl eine neue Platte anschaffen.
Bevor ich die 1 TB Platte drin hatte, steckte eine Western Digital Caviar Blue in dem Kasten.
Diese lief auch sehr schnell und bei einer Sicherung lief trotzdem noch alles.

Leider hat das Gehäuse des Servers, ein 5 Jahre altes Fujitsu Siemens Gehäuse, nur einen Schacht für 3,5 Zoll Platte und keinen Platz für weitere Schächte.

Somit muss ich wohl ein neues Gehäuse suchen um eine neue Platte zu verbauen.

Sobald dies alles geschehen ist, werde ich die Kiste mal umrüsten.
Dies gibt der Kiste dann mehr Geschwindigkeit und somit läuft auch jsync um einiges schneller.

jsync im Härtetest

Ich habe Gestern mal meine externe Sicherungsplatte komplett gelöscht.
Eigentlich wollte ich damit mal testen ob es schnellerer und effizienterer wären, wenn ich die wichtigen Ordner per tar als .tar.gz Archive sichere.

Insgesamt wäre dies eine nette Idee.
Dies hatte aber 2 Nachteile.

1.Die CPU ist extrem ausgelastet, da die Daten doppelte Verarbeitet werden müssen.
Einmal um die Daten zusammen zufügen und einmal um diese dann zu komprimieren.

2.Die Daten müssten später auch wieder dekomprimiert werden was ebenfalls wieder viel Rechnezeit kosten würde.

Also habe ich die Platte wieder mit jsync anfangen lassen zu füllen.

Leider scheint dies nun einige Tage zu dauern.
Den USB 2.0 ist leider nicht sonderlich schnell.
Und da die Platte nur mit 5400 Umdrehungen läuft, ist die Schreib- und Lesegeschwindigkeit nicht sonderlich hoch.

Mit ca. 35 MB/s kann es noch Ewigkeiten dauern.