Ich seh das Problem nicht.
Wird eine Datei z.B. auf 76K komprimiert, so gibt keine Anzahl von Datenplatten im Raid-Z auf die diese Datei ohne Extra Verschnitt verteilt werden kann. Das ist aber auch gar nicht relevant sondern die Frage ob mit Compress im Durchschnitt weniger Daten anfallen als ohne Compress bei optimaler Anzahl von Datenplatten 2^n. Und das ist eben der Fall und daher gilt die Empfehlung, Compress grundsätzlich einzuschalten zumal Compress auch bei schlecht komprimierbaren Daten kaum einen Performanceverlust hat.
Dedup prüft jetzt zusätzlich ob ein Datenblock bereits auf dem Pool liegt (Kopie) oder nicht. Wenn ja wird nur eine weitere Referenz erstellt und nichts geschrieben, es gibt da also kein Extra Problem. In der Vergangenheit war es aber so, dass die Dedup Tabellen nicht begrenzbar waren, nicht schrumpfen konnten, nicht sonderlich performant waren und daher im Schnitt viel mehr Nachteile als Vorteile mit sich brachten, daher der Rat bisher Dedup nur in ganz besonderen Fällen einzuschalten. All diese Nachteile beseitigt Fast Dedup so dass absehbar (ist ja noch nicht final und stable) vermutlich die Regel gelten kann, Fast Dedup und Compress nur in ganz besonderen Fällen auszuschalten da beides im Schnitt mehr Vorteile als Nachteile bringt. Überlegen könnte man allenfalls was eine sinnvolle Quota für alle Deduptabellen sein könnte z.B. 10% RAM wenn man nichts besonderes vorhat und für große Installationen grundsätzlich ein dedup vdev.
Wird eine Datei z.B. auf 76K komprimiert, so gibt keine Anzahl von Datenplatten im Raid-Z auf die diese Datei ohne Extra Verschnitt verteilt werden kann. Das ist aber auch gar nicht relevant sondern die Frage ob mit Compress im Durchschnitt weniger Daten anfallen als ohne Compress bei optimaler Anzahl von Datenplatten 2^n. Und das ist eben der Fall und daher gilt die Empfehlung, Compress grundsätzlich einzuschalten zumal Compress auch bei schlecht komprimierbaren Daten kaum einen Performanceverlust hat.
Dedup prüft jetzt zusätzlich ob ein Datenblock bereits auf dem Pool liegt (Kopie) oder nicht. Wenn ja wird nur eine weitere Referenz erstellt und nichts geschrieben, es gibt da also kein Extra Problem. In der Vergangenheit war es aber so, dass die Dedup Tabellen nicht begrenzbar waren, nicht schrumpfen konnten, nicht sonderlich performant waren und daher im Schnitt viel mehr Nachteile als Vorteile mit sich brachten, daher der Rat bisher Dedup nur in ganz besonderen Fällen einzuschalten. All diese Nachteile beseitigt Fast Dedup so dass absehbar (ist ja noch nicht final und stable) vermutlich die Regel gelten kann, Fast Dedup und Compress nur in ganz besonderen Fällen auszuschalten da beides im Schnitt mehr Vorteile als Nachteile bringt. Überlegen könnte man allenfalls was eine sinnvolle Quota für alle Deduptabellen sein könnte z.B. 10% RAM wenn man nichts besonderes vorhat und für große Installationen grundsätzlich ein dedup vdev.
Zuletzt bearbeitet:
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 529
Dedup Quota führt halt dazu, das dedup einfach deaktiviert wird ab dieser definierten Größe. Ich habe noch nicht rausgefunden, ob sich dieses Quota nur auf RAM bezieht oder auch auf Platzbedarf auf special vdev.
Ah gefunden:
github.com
Ah gefunden:
Fast Dedup: Dedup Quota by allanjude · Pull Request #15889 · openzfs/zfs
Motivation and Context Dedup tables can grow unbounded, which lets them consume an entire dedup vdev and so spill into the main pool, or grow too big to fit in RAM, hurting performance. This change...
github.com
Zuletzt bearbeitet:
Genau das habe ich mich auch gefragt bei dedup_quota=auto.
Hat man ein dedup-vdev ist das dessen Größe, steht aber nirgends was zu RAM
Setzt man eine feste Größe wie 2G ist das RAM,
macht ja auch keinen Sinn das auf dem dedup vdev zu begrenzen., das kann ja nix anderes
Auch ist mir noch nicht ganz klar ob sich das Limit nur auf einen oder mehrere Pools auswirkt,
ist halt alles noch sehr neu. Auch ist die Nutzung eines special vdevs für dedup möglich, wie wirkt sich da Quota aus?
Ich hab mal nachgefragt.
github.com
Hat man ein dedup-vdev ist das dessen Größe, steht aber nirgends was zu RAM
Setzt man eine feste Größe wie 2G ist das RAM,
macht ja auch keinen Sinn das auf dem dedup vdev zu begrenzen., das kann ja nix anderes
Auch ist mir noch nicht ganz klar ob sich das Limit nur auf einen oder mehrere Pools auswirkt,
ist halt alles noch sehr neu. Auch ist die Nutzung eines special vdevs für dedup möglich, wie wirkt sich da Quota aus?
Ich hab mal nachgefragt.
Fast Dedup: Dedup Quota by allanjude · Pull Request #15889 · openzfs/zfs
Motivation and Context Dedup tables can grow unbounded, which lets them consume an entire dedup vdev and so spill into the main pool, or grow too big to fit in RAM, hurting performance. This change...
github.com
Zuletzt bearbeitet:
In so einem Fall könnte es dedup Raten von 5-10 geben oder mehr.
Ich fände es bereits toll (und wohl erreichbar) wenn compress + dedup zusammen im Schnitt doppelt so viele Daten speichern könnten wie ohne, dabei vielleicht 30% schneller wäre und das bei überschaubarem und kontrolliertem RAM Einsatz.
ich lass halt bisher einfach compress laufen allerdings wie das dann wieder mit ZFS Crypt zusammenwerkelt..... da wird doch vermutlich compress vor crypt laufen oder?
Gecryptete Daten compressen ist sicher eher meist schwer weil ja da gleiche Sequenzen verlorengehen. aus AAAA wird da z.B. ZXDF Ein gutes Crypt ist wie ein gutes Random - ohne erkennbare Struktur.
Das Problem ist halt weder berufliche noch private Daten lässt man doch heute gern unverschlüsselt - z.B. wenn das System gestohlen wird, und hinter der Crypt Schicht sind alle Nutzungsdaten halt nur noch wie random Daten.
Auf alle meinen aktuell 5 verschlüsselten ZFS Servern komme ich im besten Fall auf "compressratio 1.01x" hab mal kurz bei allen nachgeschaut mit "zfs get compressratio ABC" bekommt man doch die reale tatsächliche Kompressionsrate?
Leider habe ich aktuell keinen nennenswerten unverschlüsselten Volumes.
vermutlich 0,01 für ZFS Strukturdaten oder so
Gecryptete Daten compressen ist sicher eher meist schwer weil ja da gleiche Sequenzen verlorengehen. aus AAAA wird da z.B. ZXDF Ein gutes Crypt ist wie ein gutes Random - ohne erkennbare Struktur.
Das Problem ist halt weder berufliche noch private Daten lässt man doch heute gern unverschlüsselt - z.B. wenn das System gestohlen wird, und hinter der Crypt Schicht sind alle Nutzungsdaten halt nur noch wie random Daten.
Auf alle meinen aktuell 5 verschlüsselten ZFS Servern komme ich im besten Fall auf "compressratio 1.01x" hab mal kurz bei allen nachgeschaut mit "zfs get compressratio ABC" bekommt man doch die reale tatsächliche Kompressionsrate?
Leider habe ich aktuell keinen nennenswerten unverschlüsselten Volumes.
vermutlich 0,01 für ZFS Strukturdaten oder so
Zuletzt bearbeitet:
Das wäre egal da man immer ZXDF hätte. Die Mustererkennung von compress würde wohl leiden.
Ich gehe einfach davon aus dass die ZFS Devs keine ungünstige Reihenfolge nutzen und man compress, dedup und encryption daher ohne Nachteil beliebig mischen kann.
Ich gehe einfach davon aus dass die ZFS Devs keine ungünstige Reihenfolge nutzen und man compress, dedup und encryption daher ohne Nachteil beliebig mischen kann.
Ne eben nicht - aus AAAA wird ja nur 1x ZXDF beim nächsten Mal dann CGFH beim 3. Mal dann 37AC usw .... sonst könnte man ja super easy statistische Attacken fahren.
1000 mal AAAA verschlüsselt erzeugt 1000 unterschiedliche Ergebnisse - also in einem auch nur ansatzweise modernen Cryptverfahren.
1000 mal AAAA verschlüsselt erzeugt 1000 unterschiedliche Ergebnisse - also in einem auch nur ansatzweise modernen Cryptverfahren.
Zuletzt bearbeitet:
Auf den grossen Server mit zum Teil 80 TByte belegt also "viel" Datenmaterial habe ich immer nur eine Compression Ratio von 1,00 fand ich gerade beim Nachsehen dann schon naja ernüchternd xD ich habe bisher tatsächlich noch nie nachgeschaut, weil soooo viel habe ich von Compression auch nicht erwartet vor allem dass es halt die Blockgrösse variabel macht, glaube das tut es ja. LZ4 ist bei mir aktiv - aber das wird sicher keine entscheidende Rolle sein welcher Kompressionsalgo.
Was hast Du denn da für Werte - wenn Du vielleicht was unverschlüsselt hast?
Ein keyserver nutze ich auch schon seit ein paar Jahren mit https - aber halt auf Privatnutzung optimiert - der soll nur verhindern dass wenn die Systeme gestohlen werden niemand an die Daten rankommt, finde ich super weil es die Servernutzung bequem macht und trotzdem ein grosses Sicherheitsplus ist, denn da ist Diebstahl / Einbruch doch die grösste Gefahr.
Was hast Du denn da für Werte - wenn Du vielleicht was unverschlüsselt hast?
Ein keyserver nutze ich auch schon seit ein paar Jahren mit https - aber halt auf Privatnutzung optimiert - der soll nur verhindern dass wenn die Systeme gestohlen werden niemand an die Daten rankommt, finde ich super weil es die Servernutzung bequem macht und trotzdem ein grosses Sicherheitsplus ist, denn da ist Diebstahl / Einbruch doch die grösste Gefahr.
Zuletzt bearbeitet:
Habe ich bisher auch nie kontrolliert, aktuell habe ich
zfs get all daten1 | grep compress
daten1 compressratio 1.11x -
daten1 compression lz4 local
daten1 refcompressratio 25.86x
Der wichtige Wert it refcompressratio als
refcompressratio = uncompressed_size / compressed_size
zfs get all daten1 | grep compress
daten1 compressratio 1.11x -
daten1 compression lz4 local
daten1 refcompressratio 25.86x
Der wichtige Wert it refcompressratio als
refcompressratio = uncompressed_size / compressed_size
Naja da sieht es auch nicht besser aus - immerhin 1,11 heisst ja bei Dir 10% geschenkter Platz das ist nice.
Code:
root@backupserver:/home/admin# zfs get all tank | grep compress
tank compressratio 1.00x -
tank compression lz4 local
tank refcompressratio 1.00x -Wurde denn compress erst später (nach dem Befüllen mit Daten) eingeschaltet?
bzw was zeigt
zfs get refcompressratio
Der Wert gilt ja nicht per Pool sondern per Dateisystem
Der Wert ist bei mir im root Dateisystem besonders hoch da dort nur Texte/logs liegen,
ansonst eher 1-2 und mal hoch bis 10
bzw was zeigt
zfs get refcompressratio
Der Wert gilt ja nicht per Pool sondern per Dateisystem
Der Wert ist bei mir im root Dateisystem besonders hoch da dort nur Texte/logs liegen,
ansonst eher 1-2 und mal hoch bis 10
Zuletzt bearbeitet:
Ne die wurden tatsächlich alle erst vor kurzem befüllt als ich auf grössere HDDs umgestiegen bin (also max alle so 12 Monate, 2 Server erst < 3 Monate) Komplettbefüllung von 0 per rsync - ist also auch nichts per zfs send etc irgendwas mitgewandert.
Crypt war aber natürlich immer von Anfang an aktiv.
Crypt war aber natürlich immer von Anfang an aktiv.
Zuletzt bearbeitet:
Da habe ich nichts bei mir läuft nur der Datenbereich auf ZFS - und da auch nur als ein "Batzen"
Aus 2 Gründen - 1. weil ich auch mal ZFS selber compiliere und ich da keine Probleme mit falschen Kernelmodulen etc haben oder Symboldateien usw usw will wenn man den Kernel switched und weil 2. so alte Repairtools evtl nicht mit ZFS umgehen können und ich dann z.B. Kerneltreiber nicht reaprieren kann. (mein 10 GBit läuft mit AQtion, die sind unter FreeBSD z.B. nicht im Kernel) => neuer Kernel über update und ich muss erst mal Notrepairen
bei mir läuft nur der Datenbereich auf ZFS - und da auch nur als ein "Batzen"Aus 2 Gründen - 1. weil ich auch mal ZFS selber compiliere und ich da keine Probleme mit falschen Kernelmodulen etc haben oder Symboldateien usw usw will wenn man den Kernel switched und weil 2. so alte Repairtools evtl nicht mit ZFS umgehen können und ich dann z.B. Kerneltreiber nicht reaprieren kann. (mein 10 GBit läuft mit AQtion, die sind unter FreeBSD z.B. nicht im Kernel) => neuer Kernel über update und ich muss erst mal Notrepairen
Zuletzt bearbeitet:
Hat zwar keine Auswirkung auf Compress aber sowas würde ich vermeiden, auch damit man pool und zfs properties sauber trennen kann und immer den Pool nicht verschlüsseln und darunter Dateisysteme mit Daten anlegen, verschlüsselt oder unverschlüsselt. Dann kann man auch Dateisysteme wieder entschlüsseln, mehrere Keys per Dateisystem haben oder unverschlüsselte z.B. für sync nutzen. Enc+Sync hat miserable Datenraten.
Ja das stimmt - aber ich habe nie irgendwas unverschlüsselt - da bin ich halt dann einfach etwas faul xD
Stimmt aber schon eigentlich wäre das mit "unter ZFS" Systemen sauberer. Aber glaube technisch ist das wenn man eh nur crypt nutzt kein Nachteil oder? Crypt ist doch nur eine Zwischenschicht denke ich auf irgendeinem ZFS Layer? Sicher nicht ganz ganz unten? So genau kenne ich ZFS jetzt nicht vielleicht weisst Du das was?
Ich würde vermuten das kommt weit "zeitlich" vor den RAID, Checksummen und Co ist irgendwo weit oben in der Schicht? Das doch sicher tranparent und die Nachfolgeschichten wissen gar nicht dass die Daten gecrypted sind
Aber sind halt nur Vermutungen so genau angeschaut habe ich mir das auch nicht.
Was ich halt gefunden hatte war das hier weshalb ich vermutet habe dedup ist VOR Crypt
Aber so ein "echtes" ZFS Schichtenmodell habe ich bisher noch nie gesehen - obwohl das ja u.U. interessant wäre vielleicht beim Optimieren.
Die von Dir da erwähnte / angedachte autodecrypt Lösung denke ich ist sicher wegen Multiuser und Co viel komplexer als meine - die setzt dann - nehme ich an - trotzdem eine Useraktion auf dem "Client" voraus wie Passworteingabe oder Authentifizierung/Anmeldung oder sowas?
Stimmt aber schon eigentlich wäre das mit "unter ZFS" Systemen sauberer. Aber glaube technisch ist das wenn man eh nur crypt nutzt kein Nachteil oder? Crypt ist doch nur eine Zwischenschicht denke ich auf irgendeinem ZFS Layer? Sicher nicht ganz ganz unten? So genau kenne ich ZFS jetzt nicht vielleicht weisst Du das was?
Ich würde vermuten das kommt weit "zeitlich" vor den RAID, Checksummen und Co ist irgendwo weit oben in der Schicht? Das doch sicher tranparent und die Nachfolgeschichten wissen gar nicht dass die Daten gecrypted sind
Aber sind halt nur Vermutungen so genau angeschaut habe ich mir das auch nicht.
Was ich halt gefunden hatte war das hier weshalb ich vermutet habe dedup ist VOR Crypt
Aber so ein "echtes" ZFS Schichtenmodell habe ich bisher noch nie gesehen - obwohl das ja u.U. interessant wäre vielleicht beim Optimieren.
Die von Dir da erwähnte / angedachte autodecrypt Lösung denke ich ist sicher wegen Multiuser und Co viel komplexer als meine - die setzt dann - nehme ich an - trotzdem eine Useraktion auf dem "Client" voraus wie Passworteingabe oder Authentifizierung/Anmeldung oder sowas?
Zuletzt bearbeitet:
Wenn man nicht gerade raw repliziert, ist der zfs send stream unverschlüsselt und uncomprimiert. Ein zfs send pool/enc -> pool macht dann ein unverschlüsseltes Zieldateisystem wenn der Pool selber unverschlüsselt ist.
Das Dateisystem muss natürlich unlocked sein, sonst geht nur raw send.
Das Dateisystem muss natürlich unlocked sein, sonst geht nur raw send.
nochmal zu compress
Wenn ich mir https://indico.fnal.gov/event/16264/contributions/36466/attachments/22610/28037/Zstd__LZ4.pdf anschaue, so ist das vereinfachte Ergebnis, lz4 ist schneller während zstd besser komprimiert. Kann man also wählen was einem wichtiger ist. LZ4 spart bei mir 4-10% im Schnitt. ZSTD könnte da ein paar Prozent drauflegen.
Ist natürlich nicht so wie bei Dedup wo man bei vielen Kopien auch einen Faktor 10 oder mehr haben kann und das bei Fast Dedup ohne große Nachteile wenn es so wird wie versprochen.
Wenn ich mir https://indico.fnal.gov/event/16264/contributions/36466/attachments/22610/28037/Zstd__LZ4.pdf anschaue, so ist das vereinfachte Ergebnis, lz4 ist schneller während zstd besser komprimiert. Kann man also wählen was einem wichtiger ist. LZ4 spart bei mir 4-10% im Schnitt. ZSTD könnte da ein paar Prozent drauflegen.
Ist natürlich nicht so wie bei Dedup wo man bei vielen Kopien auch einen Faktor 10 oder mehr haben kann und das bei Fast Dedup ohne große Nachteile wenn es so wird wie versprochen.
pwnbert
Urgestein
- Mitglied seit
- 30.10.2014
- Beiträge
- 4.321
Ich hab vor vielen Seiten ja mal getestet und die Screens reingestellt.
Mein Fazit war, dass LZ4 super ist, zstd recht schnell recht viel CPU-Last erzeugt und nur in speziellen Fällen sinnvoll ist. Also 10x so viel CPU-Last für ein paar % Kompression.
Hängt natürlich von den gespeicherten Daten ab und unterscheidet sich im Spezialfall wahrscheinlich dramatisch, allgemein ist die LZ4 Voreinstellung von TrueNAS ziemlich optimal, so denke ich (zumindest im Home-Server Rahmen).
Mein Fazit war, dass LZ4 super ist, zstd recht schnell recht viel CPU-Last erzeugt und nur in speziellen Fällen sinnvoll ist. Also 10x so viel CPU-Last für ein paar % Kompression.
Hängt natürlich von den gespeicherten Daten ab und unterscheidet sich im Spezialfall wahrscheinlich dramatisch, allgemein ist die LZ4 Voreinstellung von TrueNAS ziemlich optimal, so denke ich (zumindest im Home-Server Rahmen).
Besondere Stabilität von Illumos ZFS vs Integration neuester Open-ZFS Features
Diskussion: https://illumos.topicbox.com/groups...llumos-future-and-compatibility-with-open-zfs
Diskussion: https://illumos.topicbox.com/groups...llumos-future-and-compatibility-with-open-zfs
Hi
Habe mir einen USB SATA Adapter geholt, der hängt an USB 3. Kann mir wer sagen, wieso dass so langsam ist per Clonezilla? Sind SSD, Quelle alte Intel, Ziel SM893a. Handelt sich um eine simple opnsense Installation mit ZFS. Wenn ich auf dem ESXi mit durchgereichtem HBA auf napp-it kopiere, geht das 10x so schnell.
Adapter ist der hier. Host ist eine E3-1281 v3 mit 32 GB RAM.
Gruss und danke
Habe mir einen USB SATA Adapter geholt, der hängt an USB 3. Kann mir wer sagen, wieso dass so langsam ist per Clonezilla? Sind SSD, Quelle alte Intel, Ziel SM893a. Handelt sich um eine simple opnsense Installation mit ZFS. Wenn ich auf dem ESXi mit durchgereichtem HBA auf napp-it kopiere, geht das 10x so schnell.
Adapter ist der hier. Host ist eine E3-1281 v3 mit 32 GB RAM.
Gruss und danke
Trambahner
Urgestein
Der Screenshort zeigt : "2.27GB/Min", also knapp 40 MB/s . Das ist ziemlich exakt USB2-Geschwindigkeit.
Entweder
> der Port ist doch USB 2
> Treiber-/Protokollproblem zu dem Adapter oder
> die Blocksize von 512 Byte wird von Clonezilla in 512Byte-Paketen gesendet und übersättigt die USB-Controller.
Entweder
> der Port ist doch USB 2
> Treiber-/Protokollproblem zu dem Adapter oder
> die Blocksize von 512 Byte wird von Clonezilla in 512Byte-Paketen gesendet und übersättigt die USB-Controller.
Zuletzt bearbeitet:
Ich vermute mal:
Clonezille unterstützt ZFS nicht und muss daher sector by sector kopieren, also in 4K Häppchen.
Ich hatte auch schon Clonezille zum Klonen von Platten benutzt und der Sector Mode ist viel langsamer als mit ext4 oder ntfs.
Clonezille unterstützt ZFS nicht und muss daher sector by sector kopieren, also in 4K Häppchen.
Ich hatte auch schon Clonezille zum Klonen von Platten benutzt und der Sector Mode ist viel langsamer als mit ext4 oder ntfs.
Hab mal einen einfachen Versuch gemacht und meine Web-Gui Scripte in 4 Dateisysteme kopiert
- ohne dedup und compress (data)
- fast dedup
- lz4
- lz4+fast dedup
Daten sind Programmtexte, also gut komprimierbar, ca Faktor 1,7 mit LZ4
Dann nochmal kopiert, ergibt dedupratio 2.5, zusammen also einen Faktor 4,25
Daten: 64 MB, Deduptabelle 1M bei 1G Quota
Echtzeit Dedup ist schon eine feine Idee wenn man die bisherigen dedup Probleme in den Griff bekommt.
Wer erste Versuche machen möchte. bitte die rc4 nehmen
Feedback:
github.com
- ohne dedup und compress (data)
- fast dedup
- lz4
- lz4+fast dedup
Daten sind Programmtexte, also gut komprimierbar, ca Faktor 1,7 mit LZ4
Dann nochmal kopiert, ergibt dedupratio 2.5, zusammen also einen Faktor 4,25
Daten: 64 MB, Deduptabelle 1M bei 1G Quota
Echtzeit Dedup ist schon eine feine Idee wenn man die bisherigen dedup Probleme in den Griff bekommt.
Wer erste Versuche machen möchte. bitte die rc4 nehmen
Feedback:
zfs-windows-2.2.6-rc4 (and rc3) · openzfsonwindows openzfs · Discussion #399
Please provide feedback if you can, even if it is just "appears to work". I hope I have fixed the big issues during install, and mounting ?
github.com
Zuletzt bearbeitet:
Im Moment ja, da noch nicht final (momentan nur für Tests, da passt das ja mit Windows zusammen, ZFS ist da ja auch beta).
Wenn das eine gewisse Zeit in Open-ZFS drin ist und breiter genutzt wird ohne dass Probleme auftauchen, dann sehe ich das wie compress:
on per default mit einer passenden Quota.
Ob dedup + compress eine Platzersparnis von 10% (ausschließlich unterschiedliche Videos) oder 20x ergibt, hängt von den Daten ab
Wenn das eine gewisse Zeit in Open-ZFS drin ist und breiter genutzt wird ohne dass Probleme auftauchen, dann sehe ich das wie compress:
on per default mit einer passenden Quota.
Ob dedup + compress eine Platzersparnis von 10% (ausschließlich unterschiedliche Videos) oder 20x ergibt, hängt von den Daten ab
pwnbert
Urgestein
- Mitglied seit
- 30.10.2014
- Beiträge
- 4.321
Ja klar.
Ich hätte das jetzt so verstanden, wenn man z.B. verschiedene (ähnliche) VMs hat, müsste die Platzersparnis ja enorm sein, da OS und Grundprogramme (Office etc.) ja überall mehr oder weniger gleich sind...
Für den Filer daheim mit den Urlaubs und Hobby Fotos und Videos dann wohl eher unbedeutend..?
... also bezüglich dedup.
Bezüglich inline compression ist mir alles klar.
Ich hätte das jetzt so verstanden, wenn man z.B. verschiedene (ähnliche) VMs hat, müsste die Platzersparnis ja enorm sein, da OS und Grundprogramme (Office etc.) ja überall mehr oder weniger gleich sind...
Für den Filer daheim mit den Urlaubs und Hobby Fotos und Videos dann wohl eher unbedeutend..?
... also bezüglich dedup.
Bezüglich inline compression ist mir alles klar.
Dedup arbeitet auf Ebene der ZFS Datenblöcke. Dateien müssen daher nicht identisch sein, es reicht schon wenn sie in Teilen übereinstimmen um gute Dedup Raten zu erhalten. Da man den RAM Bedarf genau kontrollieren kann hat man ja auch keine großen Nachteile.
Mit einem Hybrid Pool und Special vdev (das kann auch Dedup Tabellen halten) ist man eh am besten dabei um einen Plattenpool deutlich schneller zu machen. Darauf liegen dann kleine Dateien, Metadaten und eben Dedup Tabellen. Was will man mehr.
Mit einem Hybrid Pool und Special vdev (das kann auch Dedup Tabellen halten) ist man eh am besten dabei um einen Plattenpool deutlich schneller zu machen. Darauf liegen dann kleine Dateien, Metadaten und eben Dedup Tabellen. Was will man mehr.
