DeadCrowWalking hat geschrieben:Leider wahr, aber gerade deshalb würde ich nicht auf zu lange Zeit im Voraus planen. Wenn die Platten getauscht werden müssen, ist bei einer Neuinstallation des Server oder anderen Systems immer die Möglichkeit gegeben aus dem gelernten zu profitieren und sich anders zu entscheiden.
Öhm ... das geht meiner Meinung nach an der Realität vorbei. "Neuinstallationen" des gesamten Systems spart man sich eh liebend gerne, darum haben ja Microsoft, RedHat und co. Support-Zeiträume von 5 bis 10 Jahren. Und darum setzt man bei dem Dateisystem auch ungerne auf ein totes Pferd, das einen irgendwann zur Neuinstallation zwingt. Und ZFS riecht da aus meiner Sicht schon etwas gammelig, während btrfs noch nicht ganz lebendig ist ... beides nicht die idealen Kandidaten - wie gesagt, aus meiner Sicht.
DeadCrowWalking hat geschrieben:solange nicht Btrfs auf dem Zielsystem von größerem Wert ist und eben die kleinen Risiken rechtfertigen.
Also bei mir hat btrfs durch das "fsck ist gleich fertig"-Drama derartig viel Vertrauen verspielt, dass ich mir die Sache gaaaanz entspannt aus weiter Entfernung angucke, bis das "experimental" weg ist.
DeadCrowWalking hat geschrieben:und es ist ja immer denkbar, dass sich ZFS angenommen wird im Open Source Land und auch wieder massive Weiterentwicklungen sieht.
Gerade das halte ich aus den oben genannten Gründen für unwahrscheinlich bis unmöglich. "Entwickelt" wird ZFS von Oracle, ebenso wie NTFS von Microsoft entwickelt wird. Es existieren lediglich (veraltete) Portierungen für BSD und (mit Krücke) für Linux. Für NTFS gibt es wenigstens eine Neuimplementierung unter Linux (auch veraltet, die kann noch keine Storage-Places), keine Portierung. Schon auf eine Aktualisierung von ZFS für BSD auf den aktuellen Stand wartet man seit 2010. Eine eigenmächtige Weiterentwicklung wäre wohl genau so erfolgreich, wie wenn man anfangen würde, in NTFS für Linux neue Features einzubauen.
Hinzu kommt noch die Sache mit den "Patenten", die anscheinend eine Neuimplementierung verhindern (was das GPL-Problem mit Linux lösen würde, wie bei NTFS). Ich hab da zwar keine genaue Ahnng von, aber die Grenzen zwischen "Weiterentwicklung" und "Neuimplementierung" sind fließend und wenn ich schon ein aktuelles ZFS nutzen wollen würde, käme wohl eine Lizenz von Solaris billiger als ein Streit mit dem Patentanwalt von Oracle.
DeadCrowWalking hat geschrieben:Aber das zähle ich auch mal zu den im Open Source Land üblichen eigenen Süppchen. Mir wäre lieber, man konzentriert sich auf wirklich vielversprechende Projekte wie Btrfs oder auch HAMMER(2), das ziemlich gut klingt. Auswahl zu haben ist immer gut, zu viel birgt dann aber immer wieder gefahr, dass viel gemacht wurde, aber eben nichts richtig.
Weiter oben hoffst du noch, dass die Entwickler ihre Energie auf ZFS verschleudern, statt an btrfs mitzuarbeiten ^^
Aber ich sehe das zumindest in diesem Fall anders. Die Dateisysteme scheinen unterschiedliche Grundkonzepte zu haben, wie man an die Datenverwaltung herangeht. Solche Konzepte entstehen meistens im Kopf irgendeines Informatikstudenten, der sich denkt "man könnte das doch auch ganz anders machen" und das dann einfach mal ausprobiert. Ich schätze, 99% solcher Konzepte verschwinden wieder, ohne dass du je irgendwas davon hörst ... der Rest sorgt aber für Neuentwicklungen, die gewaltigen Erfolg haben können. Es weiß ja niemand, ob das mittlerweile knapp 10 Jahre alte Konzept von ZFS nun wirklich das effizienteste ist.
Und wenn nie jemand eine Neuentwicklung wagen würde, und sich immer nur vorhandenen Projekten anschließen würde, dann würdest du jetzt immer noch BSD statt Linux nutzen.
peschmae hat geschrieben:Ich hab bedup hier schon ne Weile auf meinen Backupplatten am laufen. [...] Viel zu deduplizieren gibts da bei mir nicht wirklich, die Backups sind sowieso inkrementell mittels Hardlinks.
ehm ... so wie ich das "whole-file" von bedup verstehe, macht der eh nichts anderes, als identische Dateien zu suchen, und die dann quasi durch einen hardlink zu ersetzen. Das könnte man doch gerade auf Backup-Platten, wo es nicht vorkommt, dass nachträglich die Datei A geändert wird, nicht aber die identische Datei B geändert werden soll, doch auch auf jedem beliebigen Dateisystem per Script implementieren.
Ich denke, spannend wird das erst, wenn man anfängt, auf Blockebene zu vergleichen - da könnte das mp3 mit geänderten ID3-Tags von User A in Relation zu der Ursprungsdatei von User B auf eine Größe von einem einzigen Block zusammenschmelzen. Und um solche identischen Blöcke zu finden, könnte man die eh angelegten Checksummen vergleichen ... Blöcke mit identischer Checksumme sind höchst verdächtig, den selben Inhalt zu haben ... wozu man dann allerdings sämtliche Checksummen im Speicher halten muss, damit die Sache nicht ewig dauert.
Ich weiß ja immer noch nicht genau, was ZFS da macht, aber das könnte den großen Speicherbedarf erklären.
Aber das zeigt auch gleich, wie tückisch die Sache mit dem Deduplizieren ist. Eine 100GB große Datei zu kopieren, dauert dann auf einmal nur noch Sekundenbruchteile und der freie Speicher auf der Platte ändert sich nicht. Schreibe ich noch ein Byte an den Anfang der Datei, löse ich auf einmal eine gewaltige Kopieraktion aus, und hab plötzlich 100GB Platzbedarf auf der Platte. So ein Verhalten empfindet der unbedarfte Heimanwender vielleicht eher als "Verarschung" als als "Fortschritt".
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
