Quote

Ok, wenn es da ein gutes Werkzeug für Git gäbe, wäre das ein Argument

So wie es ausschaut kann das Git selber.
http://www.kernel.org/pub/software/scm/git/docs/ho...

Ansonsten findet man mit Google nicht wirklich aussagen wo gesagt wird das das repro kaputt sei und man ein recovery machen muss. Ich hatte nur irgendwie eine theoretische argumentation gelesen wo einer fragte was pasiert wenn man comitted etc. und der strom ausfällt und wie man im notfall ein defektes repro wiederherstellen kann.

Aussage war halt nur das alle Git Befehle atomar sind und von einem Stromausfall das nicht passiert und es höchstens in "Loose Objecte" endet die mit dem nächsten "git gc" aufruf sowieso bereinigt werden würden.

Quote

Wenn letzterer Code mit ext4 immer noch derart funktioniert, dass anderer Code der nebeläufig ausgeführt wird, entweder komplett die alte oder komplett die neue Konfiguration sieht, und dass anderer Code, der später ausgeführt wird, komplett die neue Konfiguration sieht, dann sehe ich da auch keinen Bug.

Mit deinem Code gibt es keine Probleme, Wie gesagt, das problem ist das, das die Leute eine Datei im Truncate Modus geöffnet haben also mittels "open my $fh, '>', ..." und direkt die datei überschreiben.

Bei ext3 führt das dazu das man entweder die neue datei hat, oder immer noch die alte sieht, egal was passiert. Da eben die Metainformation bei ext3 erst geupdated werden nach einem erfolgreichen schreiben.

Bei ext4 (und letztendlich auch anderen Dateisystemen, XFS etc.) werden erst Metainformationen geschrieben, das verfahren endet also entweder in einer leeren Datei oder in der neuen Datei.

Wie gesagt es ist auch so nie ein Bug, Bug sehe ich da eher wer so ein Code schreibt.

Allerdiengs hat es dazu geführt das halt zu ext4 eine mount option hinzugefügt wurde, das das verhalten dann wie ext3 macht, sprich metainformationen erst wieder zum schluß updaten. Finde ich leider etwas blöd das es gemacht wurde, da lieber der Code gefixt werden sollte. Da ich selber wohl in Zukunft nur noch XFS privat nutzen werde, wäre es toll wenn die Programme gefixt werden. Da beingt mir eine ext4 mount option wenig.

Aber gegen die schiere masse kommt man wohl immer schlecht an.

Quote

Mir hat jemand erzählt, bei ext4 reiche fsync plus rename nicht mehr aus, damit andere Prozesse danach auch wirklich die synchronisierten Daten sehen, weil das rename aufgrund der Delays beim Schreiben von Metainformationen dann auch nicht mehr atomar sei,....

Wie gesagt das sollte sich ja von alleine klären, ist so leider etwas falsch. ext4 ist in diesem Sinne sogar aggresiver, den es schreibt metainformationen schneller als es das bei ext3 getan hat, dadurch entsteht ja auch erst die ganze problematik.

Quote

Hmm, ich bin halt eher Datenbanken in der Größenordnung von 10^12 Bytes und Repositories im Bereich 10^7 Bytes gewöhnt.

10^7 Bytes für ein Repository ist aber verdammt wenig, das sind ja nur knapp 10MiB? Das können aber nur sehr sehr kleine projekte/programme sein die so wenig speicher nutzen.

Quote

Gar nicht, aber ein Versionskontrollsystem tut so etwas auch selten bis gar nicht. Und eine riesige komprimierte Datei, die man erst stückweise dekomprimieren und von der man dann noch Teile ausblenden muss, ist auch nicht gerade ideal nach einem String zu durchsuchen.

Es ist sogar idealer. :)
Zumindest was die Performance angeht.

Was mir hierzu einfällt, ich habe einmal für meinen vorherigen Arbeitgeber eine Statistische Auswertung und Report geschrieben von Apache Log Dateien. Dort waren pro tag alleine komprimiert ca 1 GiB Log Dateien produziert worden. gzip komprimiert waren es meist so 70MiB gewesen, dekomprimiert teilweise bis 1 GiB.

Es existierte vorher eine Lösung die vor dem bearbeiten die jeweilge datei erst komplett dekrompimiert hatte und dann durchgegangen ist.

Ich hatte es dann umgeschrieben und habe PerlIO::gzip genutzt. Danach ist die Zeit zum generieren der reports fast um das 10 fache gefallen. Den mit dem I/O Layer werden die Daten direkt komprimiert eingelesen und in-memory dekomprimiert. Die ersparnis die man hier an I/O hat übertrifft die cpu kosten für das dekomprimieren bei weitem. Auch heute noch ist I/O eher ein engpass als cpu power.

Aber auch wenn ich das seperate dekomprimieren aus der rechnung herausgelasen habe und schon immer eine dekomprimierte datei genutzt hatte war die lösung eine komprimierte datei zu nutzen und sie erst in-memory dekomprimieren zu lassen deutlich performanter.

Bei kleinen Dateien mag man das sicherlich nicht mercken, also einen Performance unterschied. Aber bei Dateien die unkromprimiert sehr groß sind, merkt man doch einen erheblichen Performance schub.

Quote

Auf jeden Fall hätte ich gerne etwas, was mit ganz wenigen Operationen auskommt.

Vielleicht wäre ja Git etwas für dich? Hat nur ganz wenige Befehle, nur die nötigsten. ;)

Quote

Am besten präsentiert sich ein Branch einfach als Dateisystem / Verzeichnis und versioniert sich automatisch, während ich darin arbeite, das aber so intelligent, dass nicht jedes Speichern zwischendurch um etwas auszutesten, permanent in der Versionsgeschichte abgelagert wird

Solche Versionierungen gibt es schon. Basierend jedenfalls auf FUSE. Auch Mike Schilli hatte mal so eine art versionierungssystem geschrieben das inotify nutzt und wenn es änderungen gibt es automatisch versioniert, war glaube ich mal in einem seiner Artikel im Linux Magazin.

Aber ansonsten ist hier wohl das problem was du andeutest, irgendwie muss man dem System sagen was er versionieren soll. Wenn jedes speichern zu einem commit führt wird so ein versionierungssystem wohl schnell verdammt groß mit unnötig vielen unbrauchbaren informationen.

Aber ansonsten sehe ich auch nicht wo vorhandene Systeme hier komplizierter sind. SVN kennt lediglich "svn commit" und commitet dann alles, bei git entweder manuel mackieren oder ebenso alles sofort commiten. Das ist ja schon auf das wesentliche reduziert. Ich meine 1 Befehl zum commiten ist schon wesentlich reduziert. ;)

Ansonsten lebt ein Versionierungssystem ja nicht zum commiten, sondern davon das es generell deine Programm verwaltet, daher auch Versionen erstellt (tags), das du entwicklungszweige erzeugst (branches) und das du wieder mergst. Oder auch sachen wiederherstellt, die log einschauen kannst, oder eben die daten synchronisieren kannst etc.

Es ist dann zwar toll wenn du ganz ganz viel zeit investierst um einen intelligenten mechanismus zu finden um das commiten sprich eingeben eines einzigen befehls zu sparen, aber wie machst du den rest?

Wie willst du dem versionierungssystem beibringen das es jetzt seine daten synchronisieren soll, ein branch erzeugen soll, oder mergen soll ohne das du etwas eingeben musst?

Von daher wenn dein "super versionierungssystem" nur diesen einen Befehl spart, dann ist es jetzt auch nicht unbedingt eine revolution. ;)
Last edited: 2009-07-24 18:32:43 +0200 (CEST)