Quote

"Normal" ist hier eine Definitionsfrage. Git speichert ein kompliziertes Containerformat, das einem Dateisystemimage ähnelt. Dadurch erhöht sich die Komplexität des Codes, den Git benötigt, um auf seine Repositories zuzugreifen, wesentlich. Meiner Meinung nach ergeben sich dadurch aber andereseits keine nennenswerten Vorteile.

Hier muss man den Hintergrund von Git einmal betrachten. Git wurde ja primär entwickelt als ersatz für Bitkeeper, dem VCS was vorher für Linux genutzt wurde. Und bei Bitkeeper wurde eben beklagt das es zum einen Langsam ist und die Datenmengen eben riesig wurden. Daher wollte man ein VCS schaffen das auch für große Datenmengen sehr geeignet ist und das Versionierungssystem Performant ist, und die größe sollte ebenfalls möglichst klein sein, damit über das Internet nicht all zu viel Synchronierst werden muss.

Alleine der Sourcecode von Linux 2.6.30.2 hat schon unkrompiert eine größe von 390 MiB (komprimiert mit bz2 immerhin noch 57MiB). Wenn man jetzt noch bedenkt das die benutzer zig branches erstellen jeder comit gespeichert wird etc. ist das eine verdammte menge.

Und der Punkt ist auch, es wird nicht weniger. Versionierungssysteme an sich sind ja eher so das der Datenbestand immer wächst und nicht mehr kleiner wird, von daher finde ich die entscheidung eben große Datenmengen zu handhaben und darauf ein augenmerk zu legen gar nicht so verkehrt.

Ansonsten verwaltet man auch nicht immer nur Sourcecode. Wenn man zum Beispiel eine Applikation verwaltet, nehmen wir eine beliebige Websoftware an, dann sollten auch Bilder und ähnliches gleich mitverwaltet werden. Von daher sehe ich es für mich auch nicht so das ein Versionierungssystem generell kleiner ist, als z.B. eine Datenbank.

Quote

Dadurch erhöht sich zwar die Datensicherheit des Dateisystemes oder der Platten nicht, allerdings wird die Rekonstruktion nach einem katastrophalen Datenschaden leichter, bzw. überhaupt erst möglich. Und das sehe ich bei Versionsgeschichten nunmal als Vorteil.

Kann ich verstehen, sehe ich aber etwas anders noch. Wenn ich halt Datensicherheit möchte muss halt RAID und Backups her. Bzw da es ja ein Dezentrales System ist hat man durch mehrere Klone automatisch schon praktisch sein backup, sofern es auf andere rechner abgelegt wird. Ich z.B. habe meine Daten auf drei Rechnern, mein Server, Desktop Rechner und Laptop abgelegt, wenn alles drei gleichzeitig kaputt geht müsste schon viel passieren.

Zusätzlich bieten sich ja Service wie github an, und wenn man es sowieso OSS ist, kann es ja durchaus sein das noch ein anderer eine Kopie hat. Ein dezentrales System bietet also generell schon gute unterstützung wenn etwas ausfällt da man halt kein "Single Point of Failure" hat.

Was ich halt nur sage ist das ich es wichtiger finde backups möglichst auszubauen, redundanz zu schaffen etc. und keine designentscheidungen zu treffen, falls man soetwas nicht macht, wenn man soetwas nicht macht, dann hat man Pech, simpel gesagt.

Und das absolut alles ausfällt, naja so etwas vertrauen muss man schon haben. Wenn irgendwie 4 rechner (github, server, 2 eigene pcs) zum beispiel ausfallen evtl sogar weltweit verteilt (andere entwickler?) und das auch noch alles zufällig gleichzeitig kommt es mir vor als wenn wir wohl größere probleme haben anstatt sich um sein source code zu kümmern.

Vorallem wenn man sich schon so absolute katastrophen ausmalt dann denke ich mir warum sollte es dann noch so sein das auf einem system noch etwas rettbar ist?

Aber unabhängig davon, ich weiß nicht inwiefern bei Git ein Recovery möglich ist. Nur weil es eine Binärdatei ist bedeutet es ja nicht das deswegen kein recovery mehr möglich ist. Ein kaputtes Dateisystem kannst du ja auch reparieren, und viele andere Programme bieten ja auch ein recovery an, für binärdateien.

Quote

Soweit ich gehört habe, ging es dabei um ein Verhalten in ext4, welches das übliche Verfahren zum atomaren Ersetzen einer Datei (temporäre Datei auf dem gleichen Dateisystem erstellen, mit Daten füllen, durch Umbenennen der temporären Datei die ursprüngliche Datei ersetzen) unsicher machte, wenn man hinterher keinen full sync ausführte. Vorrausgesetzt diese Information ist korrekt, so halte ich das durchaus für einen Bug, da nur der Rootbenutzer einen full sync ausführen kann und sich auch so ungefähr jedes Datenbanksystem darauf verlässt, dass dieses atomare Dateiersetzen funktioniert, um Transaktionssicherheit zu gewährleisten.

Hmm, nein das stimmt nicht ganz. Ein Bug ist es nicht da alles wirklich absolut korrekt war. Aber ich kann es trotzdem kurz erklären.

Als erstes liefert dir ein Dateisystem kein 100% Schutz. Wenn man eine Datei schließt bedeutet es nicht das die Datei auch wirklich physikalisch auf der Festplatte geschrieben wurde.

Gerade was I/O belangt spielen da ein Haufen Buffer mit. Einer ist das Dateisystem. ext4 als Beispiel speichert Dateien nicht sofort ab. Sondern es kann bis zu 60 sek. dauern bis eine datei wirklich geschrieben wird. Das wird zur Optimierung gemacht, da es sehr imperformant wäre wenn jeder I/O Zugriff auch gleichzeitig synchron mit der festplatte laufen würde. Es werden also in den 60 sek daten gesammelt, sortiert und dann intelligent auf der festplatte geschrieben.

Bei ext3 ist das aber nicht anders. Nur mit dem unterschied das die Zeit hier 5 sek. default beträgt.

Das ist aber noch nichtmal ganz die ursache, denn ext4 hat die Meta Daten anders behandelt als ext3.

Um das zu erklären kommt nun das was die anwender machen wollen, nämlich dateien ersetzen. Aber dies nur als anmerkung es ist nicht atomar.

Um ein Beispiel zu nennen. man hat eine datei "config.ini", möchte sie auslesen, etwas verändern und die datei danach neu schreiben. Das was die gängigen C Programmierer machen ist dann nach Perl Code Portiert folgender halb pseudo Perl Code.



Was an dem code faul ist sollte man wohl leicht erkennen, man öffnet die Datei mit ">" sprich im truncate modus, dadurch wird die datei komplett geleert und danach speichert man die datei, und danach schliest man die datei.

Was ist aber wenn der PC nun genau nach dem "open $write" abstürzt? Genau man hat eine Leere Datei. Der Code ist nicht atomar.

Jetzt kommen hier eben die zeiten dazu. Unter ext3 war die datei nach maximal 5 sekunden geschrieben (sofern nicht verändert). bei ext4 wird diese evtl erst nach 60sek wirklich geschrieben.

Daher auch nach dem close der datei kann wenn der pc 60 sek. danach abstürzt eine leere datei dabei heraus kommen, zumindest unter ext4.

Hier kommt nämlich noch der Punkt der Metadaten hinzu. Auch wenn man ext3 hat und der pc 2 sek nach dem close abstürzt hat man danach keine leere datei gehabt, sondern immer noch die alte datei.

Das lag daran weil ext3 die Metainformationen, sprich das die datei gelöscht wurde, und das ummappen im dateisystem auf die neue datei erst macht nachdem die datei geschrieben wurde, ext4 macht die änderungen der meta informationen aber davor, und der eigentlich inhalt wird erst später geschrieben.

Um es also kruz zu sagen, würde obriger perl code durchlaufen und der pc danach abstürzen und du hast ext3 kann es sein das du keinerlei änderungen siehst, du siehst immer noch die alte datei, da die metainformationen speich das die datei gelöscht wird, bzw auf einen neuen leeren bereich zeigt nie geschrieben wurde, bei ext4 aber schon. Das dateisystem macht letztendlich genau das was du willst. Es truncated die datei, legt eine leere neue datei an, nur das speichern kann sich halt verzögern.

Die sache ist halt, alle haben gegen das verhalten von ext3 programmiert, und schieben ext4 die schuld in die schuhe das es ein ext4 bug wäre. Wer aber solch ein Code schreibt da kann ich nur sagen, liegt der bug definitiv am programmcode und nicht am dateisystem.

Ob das verhalten nun von ext3 evtl. besser war, das ist eine andere diskussion. Mitlerweile wurde aber bei ext4 ein schalter hinzugefügt mit der dann die metadaten update wieder wie bei ext3 erst zum schluß gemacht werden kann. So kann halt der kaputte C Code weiter bestehen. Ist natürlich nur nervig wenn man kein ext3 oder ext4 nutzt.

Ich hätte es toll gefunden wenn sie den schalter bei ext4 nicht hinzugefügt hätten und die leute stattdessen mal ihre anwendung fixen.

Ansonsten kannst du schon eine datei sicher speichern. Du musst den inhalt erst in eine temporäre datei schreiben. Danach musst du den buffer frei machen, und das geht auch ohne root rechte, dafür gibt es extra die sogenannte fsync() funktion http://www.opengroup.org/onlinepubs/007908799/xsh/... das dir sicherstellt das eine datei auch wirklich auf der festplatte geschrieben wurde.

Problem ist nur, fsync() blockiert natürlich solange bis die datei wirklich geschrieben wurde, und wenn das jedes programm macht, dann kannst du dir sicher ausmallen worin das endet, die ganze I/O Puffer verpuffen praktisch wenn jedes programm ständig seine puffer so schnell wie möglich wieder frei macht. Vorallem kommen wir dann zu dem thema zu viele Dateien. KDE hat anscheind teilweise tausende kleine dateien die bei einem systemstart so geändert werden, und wenn das mit jeder datei gemacht wird, na dann prost mahlzeit.

Und deswegen sagte dann auch Ted Tso, das die ganze geschichte mit den etlichen vielen Dateien ein komplettes fehldesign ist. Man kann nicht ständig fsync() bei jedem mist aufrufen wodrunter die performance extrem leiden würde, und man kann ebenfalls nicht erwaten das kaputter C Code letztendlich unterstützt werden sollte. Daher eben der Verweis auf SQLite. Den SQLite übernimmt dann die Rolle des Speicherns der Dateien. SQLite kümmert sich um die korrekten fsync() aufrufe so das es nicht in einer totalen katastrophe für die performance endet und kümmert sich um die datensicherheit so das bei einem absturz nicht gleich alle daten futsch sind.

Quote

Ich meine, dass die relevante Datenmenge bei Datenbanken üblicherweise groß ist, bei Versionskontrollsystemen üblicherweise klein.

Naja das sehe ich nicht ganz so. Wenn ich mal auf unserer Arbeit die Datenbanken für unsere Webseiten betrachte. Der durschnitt der Datenbanken liegt bei ca 2 MiB. so ca 10 Webseiten liegen im 5-10 MiB Bereich und unsere größte ist lediglich bei ca. 200 Mib. Und das für über 100 Webseiten.

Unser CMS System was wir entwickeln hat aber durch die History knapp einen verbrauch von 70 MiB. Zumindest als ich es in Git Importiert habe. Bei SVN selber müsste das vielleicht nochmal größer sein.

Und der Punkt ist. Das Versionierungssystem wird definitiv ständig steigen, bei daten für eine webseite ist das nicht unbedingt so.

Ansonsten war das natürlich nur ein Praxis Beispiel bei uns, gibt natürlich auch Beispiele wo die Datenbank Gigabyte groß wird, allerdiengs sind da Versionierungssysteme auch nicht anders. Ich denke die verwaltung für den Linux Sourcecode wird wohl ähnlich bestimmt paar Gigabyte groß sein.

Für wenig halte ich das jedenfalls nicht, und Sourcecode selber ist da auch nicht immer klein. Ich sehes also nicht so ganz das Sourcecode grundsätzlich kleiner ist.

Quote

Zum Durchsuchen zählt auch das Durchsuchen mit Hilfe von Indizes. Ein Dateisystem stellt bereits einen hierarchischen Index in Form des Zugriffes über Dateipfade zur Verfügung.

Sofern dieser überhaupt nutzbar ist. Wenn ich in meinen Sourcecode nach einer Funktion suchen möchte, inwiefern kann mir dann die Hirachie der Verzeichnise und Dateien dafür behilflich sein?

Quote

Aber ein Beispiel. In diesem Falle ein Gegenbeispiel zu Deiner Behauptung, niemand käme auf die Idee, so abzuspeichern.

Hmm, hatte ich Behauptet das niemand so auf die Idee käme? Bin gerade faul selber nachzuschauen, aber wenn dann habe ich da mist geschrieben.

Zum anderen kann ich dir sogar noch ein anderes Beispiel nennen das Dateien so abspeichert. Nämlich Squid der Web Proxy. Deswegen würde ich wundern wenn ich das behauptet habe, da ich programme auch kenne. Wie gesagt wenn ich das behauptet habe dann war es mist.

Ich sehe es halt wie ich schon davor schrieb, beide möglichkeiten des Speicherns haben Vor/Nachteile.

Quote

Das mag für die Funktion irrelevant sein, für den Programmierer ist aber auch die Form interessant. Ich bin durchaus der Meinung, dass man in einer Sprache mit einer für den eigenen Geschmack angenehmeren Syntax besser programmieren kann.

Ds möchte ich nichtmal bezweiflen. Allerdiengs ändert es halt nichts daran das Python selber deswegen nicht besser oder schlechter wird. Soetwas sind halt so extreme subjektive sachen das sie aus jeglicher Wertung fallen.

Das ist halt wie mit dem buch beispiel. Klar kann es sein das jemand probleme mit einem Din A3 Buch hat, vielleicht zu kleine Schrift? Nur dadurch wird die eigentliche geschichte die im Buch erzählt wird nicht schlechter.

Quote

Das mag für die Funktion irrelevant sein, für den Programmierer ist aber auch die Form interessant. Ich bin durchaus der Meinung, dass man in einer Sprache mit einer für den eigenen Geschmack angenehmeren Syntax besser programmieren kann.

Komplizierter vielleicht für die Programmierer für Git, für den endanwender nicht. Und als benutzer ist mir der sourcecode dazu egal. Auch wenn du sagtest das du dir vorher den sourcecode anschaust, halte ich das für volkommen ausgeschlossen.

Wenn ich mir den Sourcecode von linux, Firefox, Gnome und alle Programme die ich nutze vorher anschauen würde, dann würde ich heute wohl noch immer kein Computer nutzen. Vorallem habe ich auch gar nicht das nötige Wissen dazu alle Sprachen überhaupt generell zu können, oder überhaupt gut genug zu kennen, und auch jedes Thema gut genug zu können als das ich den Sourcecode überhaupt bewerten könnte.

Quote

Da fehlen mir auch ein paar clevere Abstraktionen ;-)

Welche den als Beispiel? ;)