Diskussion:ZFS (Dateisystem)

Der ganze Artikel ist extrem unkritisch

klingt als wenn die Summe der Autoren sich erst durch ZFS mit Storage befasst und jetzt voll begeistert sind aber alles andere nur angelesen ist. Siehe z.b. "write hole" Geschichte... 81.21.170.84 22:42, 19. Jan. 2013 (CET)

Mehr Dateien in einem Verzeichnis als insgesamt im Dateisystem möglich

Wie kann es sein, dass in einem Verzeichnis maximal 2 hoch 56 Files sein können, wenn im Dateisystem insgesamt maximal 2 hoch 48 sein dürfen?

Meines erachtens liegt da ein Fehler vor. Die technischen Daten stimmen z.B. nicht mit dem englischen Wiki überein; dort steht etwas anderes.

Antwort von -- 91.65.217.64 15:38, 7. Nov. 2007 (CET) : Es scheint ein "Feature" von Unix Dateisystemen zu sein, das die Limits unterer Logikbereiche manchmal größer sind, als die oberen: Bei Minix z.B. mit 1KiB Clustergröße und 16bitigen Clusternummern beträgt die max. Dateisystemgröße 64MB. In den Verwaltungsstrukturen einer Datei lassen sich theo. jedoch mehr Cluster der Datei zuordnen als das gesammte Dateisystem enthält (afaik bis zu 256MB?). Dies dient iirc der flexibleren Verwaltung großer und kleinerer Dateien, sowie der Realisierung des "sparse files" Feature. Bei ZFS wäre es imho nun so, das man für jedes "echte" Verzeichnis 2^8 (56-48) soft und hard links in ein anders Verzeichnis gepackt werden könnten. -- 91.65.217.64 15:38, 7. Nov. 2007 (CET)

Copy on write

Morgen, mir fehlt hier irgendwie etwas ueber das Copy-On-Write Verfahren. Ich kenne mich mit der Technik leider nicht sonderlich gut aus, daher kann ich dazu nichts sagen, und auch aus dem, was in der englischen Wikipedia steht kann ich den Artikel leider nicht erweitern. --80.145.116.20 08:50, 22. Nov. 2006 (CET) (Beitrag war von mir. Habe vergessen mich einzuloggen. --Hco 08:51, 22. Nov. 2006 (CET))

CopyOnWrite bedeutet, dass der alte Block gelesen, in einen Backup Bereich (Volumen/Datei) kopiert wird und der aktualisierte Block auf die alte Position geschrieben wird. Microsoft NTFS nutzt genau diese Technik für die Schattenkopien (VolumeShadowCopy). Also das, was der Windows Nutzer als "Vorherige Versionen" oder bei der "Wiederherstellung" kennt. Es benötigt eine Lese- und zwei Schreiboperationen!

Bitte aber Vorsicht, CopyOnWrite wir heute zu häufig verwendet. OpenZFS, ZFS, Netapp WAFL sind nicht CopyOnWrite. ZFS könnte man als (Re)Allocate On Write oder Redirect On Write (ROW) bezeichnen. ZFS benötigt so nur die Schreiboperation des neuen Blocks. Hinweis: Bezogen auf die reinen Daten.

https://storagegaga.wordpress.com/tag/copy-on-write/ http://ram.kossboss.com/zfs-btrfs-are-row-not-cow-redirect-on-write-not-copy-on-write/ https://storagegaga.wordpress.com/tag/redirect-on-write/ http://www.networkcomputing.com/storage/all-snapshots-are-not-created-equal/1847703674 https://blogs.oracle.com/zfs/entry/current_zfs_pool_capacity_recommendations

Letztlich zeigt auch der Wikipedia Eintrag, dass COW nicht ROW ist!

https://en.wikipedia.org/wiki/Copy-on-write

Wann hört der Unfug mit dem ewigen Copy On Write auf?

Widerspruch über ZFS und "Verdampfen der Weltmeere "

Es wäre sinnvoll diese Information, die in dem eigenen Abschnitt danach widerlegt wird, nicht im ersten Abschnitt zu nennen, da sie falsch ist und tatsächlich sehr PR-artig wirkt. Sie hat für die Bedeutung von ZFS einfach nicht viel zu sagen.

Darüber zu spekulieren wann ZFS zu klein für gewisse Anwendungen wird, ist in einer deratigen Dimension meiner Meinung nach unsinnig, weil die Anforderungen an Dateisysteme heute sich wahrscheinlich in absehbarer Zeit auf Grund anderer Hardware (SSD) erheblich ändern werden. Hinzu kommt dass dieser spekulative Fall, soweit ich das verstehen kann und die bisherigen Erfahrungen kenne, auch noch lange nach erheblichen softwareseitigen Verbesserungen und Neuerungen im Dateisystembereich eintreffen wird. Somit würde ZFS wahrscheinlich längst abgelöst sein, wenn 128bit Dateisysteme benötigt würden. Man beachte nur, dass andere Entwicklungen in diesem Bereich wie ext4 oder btrfs auf eine ~64 bit umfassende Dateisystemgröße setzen und wohl kaum anders ausgerichtet sind als ZFS.

Liebe Linuxer warum stört euch ZFS ?

Das es sich um Sun Marketing handelte ist auch mir klar, hätte man gut weglassen können. Was Sun damals wohl damit ausdrücken wollte ist, das ZFS in der Implementierung recht frei ist (64Bit/128Bit/???Bit). Zur Linux Bemerkung: Wie erstellt man EXT4 Pools ohne LVM? RAID1 ist bei BTRFS soweit ich es verstanden habe ein ein RAID0 mit Möglichkeit Daten redundant zu speichern. Wenn ich falsch liege, bitte ich um Hinweise. (nicht signierter Beitrag von 87.149.14.228 (Diskussion) 13:12, 5. Okt. 2015 (CEST))

Übersetzungsfehler im Zitat

"Would exceed the quantum limits of earth-based storage" hat mit Quantenmechanik nichts zu tun. Das Wort quantum ist hier im Sinne einer extremen Steigerung zu verstehen. Eine genauere Übersetzung wäre hier beispielsweise "würde alle Grenzen irdischer Datenspeicherung überschreiten".

Auch die auf das Zitat folgende Begründung ist überdenkenswert: "da Information ohne ein Medium nicht existieren kann": Information kann auch ohne ein Medium existieren, nur für die Informationsübertragung bedarf es eines Mediums. Wobei mein Einwurf hier ohnehin rein akademisch ist, denn selbst im Hochvakuum gibt es dank Quantenfluktuation genügend virtuelle Teilchen.

"Die Gesetze der Quantenmechanik erzwingen eine Mindestmenge von Energie pro Informationseinheit": Das Wiki zu Quanteninformation meint "Diese Beobachtungen legen nahe, dass ein Qubit unendlich viel Information enthält."

"da die Information sonst auf Grund der quantenmechanischen Unschärfe verloren geht": So wie ich die Quantenmechanik verstehe, verhindert die Unschärferelation die gleichzeitige oder auch vollständige Messung der Information. -- 80.187.100.100 22:00, 30. Dez. 2009 (CET)

Kann ZFS etwa ganze Hardware-RAIDs ersetzen?

Oder wie soll ich den Artikel verstehen? --Carminox 01:19, 9. Aug. 2009 (CEST)

Ja, ZFS kann Hardware-RAIDs ersetzen und sogar überflüssig machen, da es deren Aufgaben (Paritätsberechnung, Schutz vor Schreib-Loch) effizient und performant ersetzen kann. -- Zalez71 22:12, 2. Nov. 2009 (CET)

Dazu möchte ich anmerken, dass die allermeisten Hardware-RAID-Controller es im gegensatz zu ZFS ermöglichen, Volumes zu vergrößern, also z.B. ein RAID5/6 aus vier Platten um weitere Platten zu erweitern.

Hardware RAID Controller sind für die Verwendung mit ZFS weder notwendig noch empfehlenswert. Sie stellen jedoch, im Falle eines Controllerfehlers, eine unnötige Gefährung für die Datenintegrität dar, ohne einen im Fall von ZFS, einen Nutzen zu bieten. --88.73.137.52 22:04, 8. Mär. 2023 (CET)

Apple & ZFS

Im Wiki Artikel steht, dass MacOSX 10.5 Leopard ZFS unterstützt. Das stimmt nicht. Weder 10.5 noch 10.6 Snow Leopard unterstützen ZFS. (nicht signierter Beitrag von 131.130.110.172 (Diskussion | Beiträge) 18:36, 18. Aug. 2009 (CEST))

Datumsbereich?

Ist was bekannt zum Thema Datumsbereich? -- 134.93.51.36 22:17, 2. Sep. 2009 (CEST)

NetBSD hat einen init. Portierung von ZFS begonnen

http://www.netbsd.org/changes/changes-6.0.html#zfs --91.43.94.54 14:57, 15. Jan. 2010 (CET)

Adressierung per Byte, nicht per Block?

Was ich nicht ganz verstehe: Warum unterstützt das Dateisystem mit seinen effektiv 64 Bit großen Zeigern "nur" 16 EB pro Partition? Ext2 z.B. unterstützt 16 TB auch nur, weil seine 32-Bit-Pointer blockweise adressieren, woraus folgt: 4096 Byte/Block * 2^32 Byte = 17592186044416 Byte = 16 TB. Die 16 EB bei ZFS entsprechen nämlich exakt 2^64 Byte (= 16 * 2^60 Byte), wodurch sich auf der Festplatte jedes einzelne Byte adressieren lässt , was technisch gesehen keinen Sinn macht, weil Festplatte blockweise adressiert werden. Aus Informatikersicht also ein Schwachfug, schließlich ließen sich mit 64-Bit-Zeigern bei 4 KB pro Block satte 64 ZB adressieren! --Carminox 03:18, 19. Aug. 2011 (CEST)

Für mich enthält deine Aussage "Schwachfug" gleich zwei Dinge die ich für fehlinterpretiert halte. Erstens ist ZFS nicht auf 64Bit begrenzt und die 128Bit sind sowieso eine Grenze, die wir alle nicht mehr brauchen werden. Der zweite Punkt ist, ZFS arbeitet mit unterschiedlichen Blockgrößen zwischen 512 Byte und ich glaube aktuell bis zu 1MiB. Statt jetzt in 512 Byte zu rechnen, könnte man gleich in Byte rechnen und eine Rechnerei von ggf. 4KiB Blöcken einschließlich Offset zu arbeiten mach keinen Sinn. Dann schon lieber gleich 64Bit oder 128Bit. Ich halte dies für sinnvoll. (nicht signierter Beitrag von 84.163.243.151 (Diskussion) 11:50, 16. Jan. 2016 (CET))

Features, Versionen und Daten

Ich fände es schön wenn ein Feature mit einem Datum gekennzeichnet ist auch mit einer ZFS-Versionsnummer versehen wird. So hat man beide Informationen, Versionsnummer und Datum. Also als Beispiel: "Seit Juli 2009 (Version 17) ist auch RAID-Z3, also eine RAID-Z-Implementierung mit 3 Paritätsbits, verfügbar." --Ruiin 13:03, 23. Aug. 2011 (CEST)

Weiterentwicklung

Die engl. Wikiseite zeigt das es erhebliche Weiterentwicklungen gibt z.b. bei native ZFS für Linux. Würde es nicht Sinn machen diese Seite durch die engl. Fassung zu ersezten, notfalls auf Deutsch übersetzt-- 109.44.7.229 13:15, 8. Feb. 2012 (CET)

Du meinst Alternativimplementierungen, denn Solaris ist von Features her viele weiter. Wird denn überhaupt bei Linux daran weiterentwickelt?--95.91.58.72 18:02, 9. Feb. 2012 (CET)

Kritik

Ich finde es irgendwie merkwürdig, dass FAT32 als überlegen ggü. ZFS dargestellt wird. Beschränkung hinsichtlich Größe der Partitionen und Dateigröße/-attribute sind für SOHO Zwecke ein K.O.-Kriterium.--95.91.58.72 18:11, 9. Feb. 2012 (CET)

Die Kritik bezieht sich großteils auf den angeblichen Overhead durch 128 bit breite Zeiger. De facto arbeitet ZFS jedoch mit 64-bit, nirgendwo werden 128-bit breite Zeiger durch den Bus geschickt. Einzig auf der Platte ist der Platz auf 128 bit reserviert, vulgo die ersten 64 bit immer auf 0 gesetzt. Man könnte es auch so ausdrücken: ZFS ist 64-bit mit Vorwärtskompatibilität zu möglicherweise zukünftigen 128-Bit-Zeigern und diese Tatsache wird im Marketingsprech ausgelassen. Quelle weiß ich blöderweise gerade nicht, aber es ist in den frühen Blogeinträgen von Sun-Mitarbeitern mehrfach erwähnt. Das heißt nicht, dass ZFS nicht kritikabel ist, aber das Rumreiten auf diesen Overhead ist falsch. --92.224.154.196 14:10, 7. Jul. 2013 (CEST)

ZFS Dateisystem

Der Begriff Dateisystem ist nicht passend. Auch Volume Manager alleine wäre nicht korrekt. Wie bekommt man ZFS und den Inhalt also Platte, RAID, Pool, LUN, Share, Snapshot, Compression, Deduplication, Send/Receive, Datenintegrität etc. unter einen passenden Begriff? Mir selbst fällt dazu auch kein passender Begriff ein. Dateisystem alleine reicht da nicht! (nicht signierter Beitrag von SchaubFD (Diskussion | Beiträge) 09:48, 21. Aug. 2015 (CEST))

Zur Vollständigkeit gehört Fuse als Erwähnung schon dazu, aber es ist wie Adapter auf einen Formel1-Felge zu schrauben, damit 145er Reifen drauf passen. Kurz, es war zwar eine Möglichkeit ZFS auf Systemen zum Laufen zu bekommen, die mit ZFS nichts am Hut hatten. Schlechter lief ZFS nirgendwo sonst. Es war so auch eine der Möglichkeiten ZFS mit vielen Fehlaussagen zu belegen. Besser wäre es diese Links komplett zu entfernen! Meine Aussage bezieht sich aber nur auf Fuse und ZFS. Fuse kann durchaus in anderen Bereichen sinnvoll sein!

ZFS ist Allocate On Write!

Es müssen alle Dateisysteme mit dem Begriff CoW oder CopyOnWrite neu beurteilt werden. Die jeweiligen Aussagen sind nicht korrekt in Wikipedia wiedergeben. Ich musste selber feststellen, das ich mit CoW bei ZFS falsch lag.

Im folgenden lasse ich Operationen für Metadaten weg. So wie ich es derzeit verstehe ist es wie folgt:

CopyOnWrite ist definitiv das NTFS Dateisystem. Es liesst die Daten aus dem Originalblock, schreibt diese Daten in eine Backupdatei und überschreibt wenn möglich den alten Block mit den neuen Daten. Es sind grundsätzlich eine Leseoperation und zwei Schreiboperationen nötig.

CopyOnFirstWrite soll bei EMC Snapview verwendet werden. Es gleicht sehr stark dem CopyOnWrite, hat sicherlich die gleichen Operationen mit dem Unterschied, dass EMC Snapview in ein Volumen und nicht wie bei NTFS in eine Datei schreibt.

WriteAnywhere ist definitiv das Netapp WAFL Dateisystem. Es ließt den Originalblock und schreibt den aktualisierten Block an eine andere Position im Flex-Volume. WAFL bedeutet auch WriteAnywhereFileLayout. Es benötig eine Lese und eine Schreiboperation.

AllocateOnWrite ist definitiv ZFS/OpenZFS. Es schreibt nur die aktualisierte Information an eine andere Position. Es benötigt nur einen Schreibvorgang. Da in dem genannten Dokument der Begriff ReallocateOnWrite genutzt und AllocateOnWrite nicht, hier ein Hinweis: Write Anywhere kann man auch als ReallocateOnWrite sehen. Der Unterschied bei ZFS zu WAFL ist, dass der ZFS Block keine feste Größe hat. Deshalb muß WAFL den Quellblock lesen, die enthaltenen Information neu organisieren und in ein anderes Ziel schreiben.

Das Problem mit CopyOnWrite ist, dass gerade in WAFL und ZFS diese CoW Idee verbessert wurde. Weder ZFS noch WAFL sind aber CopyOnWrite, auch wenn die Idee dahinter recht ähnlich klingt. Leider hat sich diese Bezeichnung CopyOnWrite überall festgebrannt, selbst bei den Entwicklern von ZFS findet es Erwähnung. Es liegt nun an uns, diese Ausdrücke in Wikipedia korrekt wieder zu geben.

An Wikipedia: Entschuldigt die häufigen Änderungen, aber dass Thema ist wirklich mit sehr viel Sucharbeit verbunden, an viele Informationen kommt man durch Closed Source nicht heran und in vielen Beiträgen macht man es sich einfach, nur CopyOnWrite zu erwähnen. Selbst im unten genannten SNIA Artikel findet man teils noch unterschiedliche Darstellungen zwischen Text und späterer Erklärung. Ggf. wäre es besser gewesen überall von einer CopyOnWrite Idee, als von einer CopyOnWrite Technologie zu sprechen. Es wäre aber auch nur der halbe Weg.

Weitere Information: SNIA - Disk-based Restoration Technologies aus 2007.pdf (nicht signierter Beitrag von SchaubFD (Diskussion | Beiträge) 09:00, 28. Jun. 2016 (CEST))

Erstmal Danke für die Hinweise. Ich halte die "AllocateOnWrite" Idee allerdings für nicht hinreichend aus der Literatur belegt. In der angefügten Quelle ist davon überhaupt nicht die Rede, und die dort zu findende Copy-On-Write Definition betrifft einen anderen Sachverhalt (mehrere Platten mit unterschiedlicher Nutzung). Zudem sollten die Belege im Artikel selbst aufgeführt werden, nicht in der Diskussionsseite. Dass die ZFS-Autoren von Copy-On-Write sprechen ist richtig, und dadurch allerdings auch normativ für die Verwendung des Begriffs, in meinen Augen. Ich sehe nicht, dass die Wikipedia hier begriffsbildend agieren sollte - die englische Wikipedia tut das übrigens auch nicht und spricht bzgl. ZFS von Copy-On-Write. Ich habe die Änderung deshalb wieder rückgängig gemacht. Auch die Bemerkung zu Defragmentierung halte ich für falsch, die Behandlung des Sachverhalts ist allerdings insgesamt noch unbefriedigend. Die Problematik mit Fragmentierung bei ZFS ist wichtig und könnte einen eigenen Absatz vertragen. Aber so einfach wie dargestellt ist es leider nicht. Pangamut (Diskussion) 09:41, 5. Sep. 2016 (CEST)

Bitte sehe Dir den Wikipedia Eintrag https://en.wikipedia.org/wiki/Copy-on-write an. Hier steht folgendes:

When implementing snapshots, there are two techniques:

The original storage is never modified. When a write request is made, it is redirected away from the original data into a new storage area. (called "Redirect-on-write" or ROW)

When a write request is made, the data is copied into a new storage area, and then the original data is modified. (called "Copy-on-write" or COW)

1) ZFS kopiert keine Originaldaten weg und 2) ZFS überschreibt keine Originaldaten, es kann also kein COW sein! Ob man es nun Redirect On Write, Allocate On Write nennt ist egal. Es ist aber definitiv kein reines COW! Ähnlich ist es bei Netapp WAFL, hier stehen die ersten beiden Buchstaben schon für Write Anywhere. Die Netapp / Sun Auseinandersetzung kennt man ja ggf. Wenn dann widerspreche bitte dem COW Wiki Eintrag, wenn Du dies besser kennst. (nicht signierter Beitrag von 91.43.248.143 (Diskussion) 10:16, 27. Nov. 2016 (CET))

relativer, unsachlicher Begriff

"..Hierzu zählen die enorme maximale Dateisystemgröße.."

Was bitte heißt 'enorm'? Was dem Enen sin Uhl ist dem anderen sin Nachtigall - das Wort 'enorm' besagt nichts und könne gestrichen werden. (nicht signierter Beitrag von 84.129.124.7 (Diskussion) 20:58, 22. Nov. 2016 (CET))

Maximale Dateigröße ist 2^63 da signed.

Die maximale verwendbare Dateigröße ist genau 2^63 da fseek() eine signed long erwartet. Nicht wie angegeben 2^64. --Rubberduck09 (Diskussion) 11:27, 2. Aug. 2018 (CEST)

Abschnitt Trivia - Zitat von Jeff Bonwick

Jeff Bonwick erklärt seine Aussage hier: https://blogs.oracle.com/bonwick/128-bit-storage:-are-you-high

Ob das physikalisch ernst gemeint ist, wage ich zu bezweifeln: "the entire mass of the computer must be in the form of pure energy"

Der nachfolgende Absatz Bemerkung ist völlig falsch. Da verwechselt jemand Entropie (Informationstheorie) mit Entropie in der Physik.

Ich schlage vor das Orginalzitat von Jeff Bonwick zusammen mit der Übersetzung ins Deutsche stehen zu lassen. Allen nachfolgenden Text zu entfernen und dafür den Verweis auf Jeff Bonwicks Blogeintrag, mit seiner Erklärung, einzufügen. --178.202.162.20 23:26, 12. Jan. 2020 (CET)

Korrekte Implementierung von Schaltsekunden ?

Wurde denn im ZFS mal eine korrekte bzw. angemessene Implementierung der Zeitstempel unter Berücksichtigung der bisher aufgelaufenen Schaltsekunden zumindest bei der Definition der ZFS-Struktur umgesetzt (UTC = TAI - SummeSchaltsekunden), gibt es da einen Quelle ? -- 92.211.175.11 23:37, 15. Jan. 2020 (CET)