[Sammelthread] ZFS Stammtisch

Also ich habe das eben mal auf einem Testsystem probiert während eine VM lief, die in diesem Pool liegt. Der erste Send/Receive dauerte natürlich ein paar Minuten, bis das komplette Filesystem auf dem Ziel Pool erstellt war (~13GB):

zfs send -R pool-1/daten@snap-1 | zfs receive backup/backup-pool

Ich hab dann einwenig in der VM rumgespielt, danach wieder einen Snapshot gemacht und den dann wieder mit Send/Receive rüber geschoben:

zfs send -i pool-1/daten@snap-1 pool-1/daten@snap-2 | zfs receive backup/backup-pool

Das ganze dauerte dann nur ein paar Sekunden. Scheint also, als ob nur die Änderungen in der Datei geschrieben werden, was ja perfekt wäre.

Nur check ich das mit den ganzen Paramtern noch nicht ganz. Vor allem soll das ja automatisiert laufen und im Wechsel mit zwei externen Platten. Wenn da jetzt immer der Vor-Snap angegeben werden muss, wird das wahrscheinlich gar nicht so einfach gehen. Hat da zufällig jemand schon was ähnliches am laufen?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
OK, ändert sich ein Zeichen in der VM, ändert sich auch die Imagedatei.
Frage an Wissende:
Wenn das OS beim planen/machen eines neuen Snapshots eine Änderung der Datei im Vergleich zum letzten gemachten Snapshot feststellt wird:
* die Datei wieder komplett neu geschrieben?
* oder nur die Änderungen in der Datei - wie auch immer -festgehalten/geschrieben?



Da wird nichts "festgestellt". ZFS ist ein copy-on-write fs, d.h. _jeder_ Block wird in einen freien Bereich geschrieben, danach wird der pointer umgesetzt, bzw. im Fall von Snapshots bleibt eine Referenz auf den alten Block und eine neue wird hinzugefügt. Snapshots bedeuten quasi nur "gib beim copy-on-write den alten Block nicht frei".
 
Da wird nichts "festgestellt". ZFS ist ein copy-on-write fs, d.h. _jeder_ Block wird in einen freien Bereich geschrieben, danach wird der pointer umgesetzt, bzw. im Fall von Snapshots bleibt eine Referenz auf den alten Block und eine neue wird hinzugefügt. Snapshots bedeuten quasi nur "gib beim copy-on-write den alten Block nicht frei".
Kann eine Datei kann aus mehreren Blöcken bestehen oder ist eine Datei ein Block?
 
Also ich habe das eben mal auf einem Testsystem probiert während eine VM lief, die in diesem Pool liegt. Der erste Send/Receive dauerte natürlich ein paar Minuten, bis das komplette Filesystem auf dem Ziel Pool erstellt war (~13GB):



Ich hab dann einwenig in der VM rumgespielt, danach wieder einen Snapshot gemacht und den dann wieder mit Send/Receive rüber geschoben:



Das ganze dauerte dann nur ein paar Sekunden. Scheint also, als ob nur die Änderungen in der Datei geschrieben werden, was ja perfekt wäre.
Bei mir scheint die Sonne;)... Gewissheit bringt ein md5sum der Imagedatei. Hilfreich ist dabei den Snapshot und die Erzeugung der Checksumme zu machen wenn die VM runtergefahren ist.
Nur check ich das mit den ganzen Paramtern noch nicht ganz. Vor allem soll das ja automatisiert laufen und im Wechsel mit zwei externen Platten. Wenn da jetzt immer der Vor-Snap angegeben werden muss, wird das wahrscheinlich gar nicht so einfach gehen. Hat da zufällig jemand schon was ähnliches am laufen?
Nur mal so aus Neugier: Was möchtest Du denn eigentlich erreichen?
Für ein revisionsfähiges Backup ist das Verfahren kaum einsetzbar. Anders wäre es vielleicht wenn deine VM eine weitere Platte/Partition hätte für Daten die während des Betriebes der VM gemountet werden kann. Am Ende hast du eine VM mit System, Daten am laufen und wenn nötig mountest Du noch den DatenSnap-vor-einer-Woche-erstellt an den mountpunkt /blafasel während der Laufzeit.
Deine Idee mit den 2 Festplatten - aufbauend auf einen Snap-Urknall könntest Du für jede Festplatte ein inkrementellen Snap erzeugen. So würde aber jede Festplatte für sich stehen.
 
Nur mal so aus Neugier: Was möchtest Du denn eigentlich erreichen?

Ich möchte einfach die Backups an zwei verschiedenen Stellen haben, damit bei Blitzschlag (USV habe ich :), Brand oder Diebstahl noch ein Backup mit max einem Tag Verlust vorhanden ist. Die Sache mit den Snaps und Send/Receive wäre natürlich hier echt klasse, denn damit hätte ich dann auf jeder USB Platte alles und das bei super kurzen Backup-Zeiten und sicher auf einem ZFS Pool.
Ich blick das nur noch nicht ganz mit den Parametern. In den Oracle Docs find ich z.B. manche Parameter gar nicht (z.B. "... receive -vudF ...", die in einigen User Script-Beispielen verwendet werden. Gibt es da irgendwo eine detailierte Aufstellung davon?
Ausserdem macht mir die Automatisierung des ganzen noch Kopfzerbrechen. Ich hoffe ich finde da noch was dazu.
 
Suppi, danke, genau das hab ich bisher nicht gefunden.

"man zfs" funzt bei nas4free nicht, wahrscheinlich man nicht installiert.

Ok, werde mich mal einlesen.

Fals aber trotzdem jemand schon soetwas automatisiertes am Start hat, darf er mir das natürlich gerne zur Verfügung stellen :)
 
Suppi, danke, genau das hab ich bisher nicht gefunden.

"man zfs" funzt bei nas4free nicht, wahrscheinlich man nicht installiert.

Ok, werde mich mal einlesen.

Fals aber trotzdem jemand schon soetwas automatisiertes am Start hat, darf er mir das natürlich gerne zur Verfügung stellen :)

Kann Dir da leider nichts anbieten. Bevor Du aber Zeit investierst lies das kurz >> http://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-93.html#post19431657 <<. Ich hatte sowas auch vor. Die aufgetretenen Probleme bei der Nutzung des Snapshot waren aber massiv. Allerdings bei Diebstahl, ... oder ... ist das 1000mal besser als garnichts zu haben. Wenn Du die VMs für den Snapshot runterfährst sollte es bei Dir gehen.

http://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-93.html#post19431657
 
hallo in die runde.
ich hab mal eine frage (vermutlich kennt es schon jeder ausser mir).
ich habe mit zfs pools angefangen zu spielen. allerdings nach einem reboot ist der pool von dateisystem sicht aus leer.
zpool list zeigt allerdings an dass noch der speicher allokiert ist.
exportiere und importiere ich den pool sind auch alle daten wieder im dateisystem sichtbar.
kenn ihr diesen "bug" bzw eher den fehler in meinen einstellungen?
irgendwie leider schwer zu zfs allgemein sachen über google zu finden.
 
Schick doch mal du für ein OS hast, was zur Hardware und schicke ein paar Outputs wie z.B zpool list und zfs list vor und nach reboot.
 
LZ4 und Cache
ZFS ist ja deshalb so schnell beim Lesen, weil es vieles im RAM-Arc Cache hält. Wird etwas da nicht gefunden, wird im 10x langsameren L2Arc (SSD) gesucht. Ist es da auch nicht, dann halt von Platte. Die ist nochmal 10x langsamer.

Ist der zu lesende Block im L2Arc, wird er von da gelesen. Aus Sicht der CPU ist das richtig lahm. Je weniger Daten gelesen oder geschrieben werden müssen, desto schneller. LZ4 im Cache ist also sehr sinnvoll. Es ist ja die effektive Leseperformance.

Nochmal zum Thema da ich es trotzdem nicht ganz verstehe...(vielleicht habe ich auch nur ein Denkfehler.)

So wie ich das verstehe ist es so, dass eine CPU zB in einer Sekunde mehr Reserven bzw. mehr verarbeiten kann als den Durchsatz einer SSD in einer Sekunde (egal ob nun Leseraten oder Access-Time), sodass die CPU sich eher langweilt weil sie auf den L2Arc-Cache warten muss. Wenn der L2Arc-Cache jetzt komprimiert ist durch LZ4 muss weniger gelesen werden, sodass es somit einen positiven Effekt hat, auch wenn die CPU jetzt mehr Zeit brauch es zu dekomprimieren.
Was ist aber nicht ganz logisch finde bzw. im Gegensatz steht zu "CPU langweilt sich/muss auf L2Arc warten" ist, dass wenn man mal Tests/Benchmarks von egal welcher Komprimier-Methode (oder Verschlüsselung) macht, dass die CPU ohne immer einen höheren Durchsatz schafft. Das zeigt ja, dass die CPU sich doch nicht sooo langweilt bzw. es Zeit in Anspruch nimmt die Cache-Daten zu "dekomprimieren" oder?
(Bei einer SSD ist die Dekomprimierung von LZ4 durch die CPU noch schneller (555MB/s), aber eine PCI-SSD hätte wahrschl. abhängig von der CPU dann einen Nachteil durch LZ4 auf dem Cache, oder?)

PS: ist LZ4 automatisch bei OmniOS beim L2Arc aktiviert?
 
Zuletzt bearbeitet:
12.04.2 LTS (GNU/Linux 3.5.0-34-generic x86_64)
Linux nas 3.5.0-34-generic #55~precise1-Ubuntu SMP Fri Jun 7 16:25:50 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

vor dem reboot:
Code:
zpool list
NAME      SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
storage  7.25T  5.82T  1.43T    80%  1.00x  ONLINE  -
Code:
zfs list
NAME      USED  AVAIL  REFER  MOUNTPOINT
storage  5.82T  1.31T  5.82T  /storage

ls /storage : alles da


nach dem reboot:
Code:
zpool list
NAME      SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
storage  7.25T  5.82T  1.43T    80%  1.00x  ONLINE  -
Code:
zfs list
NAME      USED  AVAIL  REFER  MOUNTPOINT
storage  5.82T  1.31T  5.82T  /storage

ls /storage : leer

und wie gesagt export und import fixed es.
 
Nochmal zum Thema da ich es trotzdem nicht ganz verstehe...(vielleicht habe ich auch nur ein Denkfehler.)

So wie ich das verstehe ist es so, dass eine CPU zB in einer Sekunde mehr Reserven bzw. mehr verarbeiten kann als den Durchsatz einer SSD in einer Sekunde (egal ob nun Leseraten oder Access-Time), sodass die CPU sich eher langweilt weil sie auf den L2Arc-Cache warten muss. Wenn der L2Arc-Cache jetzt komprimiert ist durch LZ4 muss weniger gelesen werden, sodass es somit einen positiven Effekt hat, auch wenn die CPU jetzt mehr Zeit brauch es zu dekomprimieren.
Was ist aber nicht ganz logisch finde bzw. im Gegensatz steht zu "CPU langweilt sich/muss auf L2Arc warten" ist, dass wenn man mal Tests/Benchmarks von egal welcher Komprimier-Methode (oder Verschlüsselung) macht, dass die CPU ohne immer einen höheren Durchsatz schafft. Das zeigt ja, dass die CPU sich doch nicht sooo langweilt bzw. es Zeit in Anspruch nimmt die Cache-Daten zu "dekomprimieren" oder?
(Bei einer SSD ist die Dekomprimierung von LZ4 durch die CPU noch schneller (555MB/s), aber eine PCI-SSD hätte wahrschl. abhängig von der CPU dann einen Nachteil durch LZ4 auf dem Cache, oder?)

PS: ist LZ4 automatisch bei OmniOS beim L2Arc aktiviert?

Selbst bei einem lahmen HP Microserver bringt LZ4 compress im L2ARC SSD Lese-Cache bis zu 50% mehr Durchsatz. CPU ist also praktisch egal, siehe L2ARC Compression - illumos - illumos wiki

Ansonsten:
LZ4/L2ARC compress ist in development in Illumos.
OmniTi werden die ersten sein, die das haben -derzeit noch nicht- siehe
ReleaseNotes
 
Zuletzt bearbeitet:
@ty_ascot

soso, du arbeitest also direkt auf dem Pool und hast gar kein Dataset drunter? Geht zwar, ist aber nicht üblich.
mach doch mal: zfs get all storage |grep mount

cu
 
Selbst bei einem lahmen HP Microserver bringt LZ4 compress im L2ARC SSD Lese-Cache bis zu 50% mehr Durchsatz. CPU ist also praktisch egal, siehe L2ARC Compression - illumos - illumos wiki
Trifft die Einschränkung/Tatsache für lz4_compress feature für pool/dataset auch für LZ4 compress im L2ARC zu:
...
How significant the above performance improvements depends largely on your dataset composition. If you have a reasonable mix of compressible data, then the gains might be significant. On the other hand, if you're dealing mostly with incompressible stuff (e.g. multimedia streaming), LZ4 isn't going to help you much at all.
...

So das ein dataset was ausschließlich aus bereits hoch komprimierten Dateien(z.B. mpeg, jpeg, mp3) besteht auch nicht von der "LZ4 compress im L2ARC" profitiert und dem zu folge kein mehr an Durchsatz zu erreichen ist?

Könnte der zusätzliche(vergebliche) Aufwand einer lz4 Komprimierung einer bereits hoch komprimierten Datei(bzw. der Blöcke der Datei) bzw. der zusätzliche(vergebliche) Aufwand einer lz4 Dekomprimierung beim Lesen der Datei den Durchsatz merklich/nachweisbar reduzieren?

LZ4 Compression - illumos - illumos wiki
Ansonsten:
LZ4/L2ARC compress ist in development in Illumos.
OmniTi werden die ersten sein, die das haben -derzeit noch nicht- siehe
ReleaseNotes
 
Dein Problem wird wahrscheinlich sein dass der Zpool nicht gemountet wird, das hat nichts direkt mit ZFS zu tun.
Das ist ein Ubuntu/ZoL spezifisches "Problem" wenn man nicht alle Pakete aus der PPA installiert, passiert wenn man sich nicht genau an die "Anleitung" hält. ;)
Du bist da aber nicht der Einzige dem dies passiert, man kann davon in etlichen Foren lesen, in Kommentaren zu Blogs und auch mehrfach in der offiziellen Mailingliste.
Mit den richtigen Suchbegriffen findet man dazu auch ganz schnell etwas. ;)
https://www.google.de/search?hl=de&q=zfsonlinux+ubuntu+auto+mount

Dafür ist nämlich das Paket mountall aus der Ubuntu-PPA zuständig, wenn man das nicht mit installiert wird beim Starten auch nichts gemountet.
Du musst den Pool auch nicht exportieren und wieder importieren, das ist absolut nicht notwendig und ist auch nicht empfehlenswert. Einfach zfs mount -a eingeben, dann werden alle zfs Dateisysteme unter ihrem jeweiligen Mountpoint gemountet. Du kannst die Dateisysteme auch wo anders hinmounten, mit zfs set mountpoint=/mein/mountpoint/meinmountordner poolname .

Sollten trotz des mountall Paketes die Dateisysteme nicht automatisch beim Neustart gemountet werden, leg dir zfs mount -a in den "Autostart", also als Cron oder Init-Script oder /etc/rc.local usw. Es gab in der Vergangenheit nämlich ab und an Probleme mit den mountall Script, verursacht durch die tolle Releasepoliktik von Comical. Wechsel einfach zum Original, weniger Ärger.
 
Zuletzt bearbeitet:
Wenn es nur vor allem um Storage geht und die Hardware unterstützt wird,
dann ist ZFS unter Solaris & Co am ausgereiftesten/schnellsten/aktuellsten auch einfachstem,
gefolgt von BSD (FreeeNas&Co) und dann kommt erst Linux.

Kann sich ändern (Linux wird aufholen). ist aber derzeit Fakt.
Bei Solaris ist ZFS das default/einzige FS, bei den anderen ist es eins von vielen.
 
Zuletzt bearbeitet:
Naja, grundsätzlich sieht es aber genau umgekehrt aus, dieses Aussage stimmt wirklich nur rein für den Anwendungenzweck ZFS/Storage. Ich finde es wichtig dass noch mal so zu unterstreichen weil es sonst noch jemand überliest oder falsch versteht.

Die breitere und performantere Hardware-Unterstützung hat dann doch Linux. Viel Spaß mit "ungewöhnlicher Hardware" oder Consumer-Hardware unter Solaris. ;) Die wird dort leider oft gar nicht unterstützt weil dort zu wenig Treiber-Entwickler dran arbeiten und es für den zahlenden Kundenstamm nicht relevant ist. Ich hatte damals viel Spaß mit einer älteren Realtek-Karte unter OpenSolaris und dann mit einer vor ein paar Wochen erschienen Intel. Die Intel wurde nicht mal korrekt erkannt, die Realtek lief äußerst instabil. Unter Windows und Linux liefen beide anstandslos.

Stromverbrauch im Idle unter Solaris ist auch etwas höher als unter Linux, in Solaris 11 kann man so weit ich weiß keine Festplatten mehr automatisch Schlafen legen, dieses Feature wurde entfernt. Ist das in den offenen Varianten auch so und hat sich in Solaris 11 da schon wieder etwas getan?

Für Geschäftsanwendungen uninteressant, für einen Homeserver dann vielleicht doch recht interessant.
 
Zuletzt bearbeitet:
Naja, grundsätzlich sieht es aber genau umgekehrt aus, dieses Ausage stimmt wirklich nur rein für ZFS. Die breitere und performante Hardware-Unterstützung hat dann doch Linux. Viel Spaß mit "ungewöhnlicher Hardware" oder Consumer-Hardware unter Solaris. ;) Die wird dort leider oft gar nicht unterstützt weil dort zu wenig Treiber-Entwickler dran arbeiten und es für den zahlenden Kundenstamm nicht relevant ist. Ich hatte damals viel Spaß mit einer älteren Realtek-Karte unter OpenSolaris und dann mit einer vor ein paar Wochen erschienen Intel. Die Intel wurde nicht mal korrekt erkannt, die Realtek lief äußerst instabil.

Stromverbrauch im Idle unter Solaris ist auch etwas höher als unter Linux, in Solaris 11 kann man so weit ich weiß keine Festplatten mehr automatisch Schlafen legen, dieses Feature wurde entfernt. Ist das in den offenen Varianten auch so und hat sich in Solaris 11 da schon wieder etwas getan?

Für Geschäftsanwendungen uninteressant, für einen Homeserver dann vielleicht doch recht interessant.

Naja...
Solaris läuft perfekt mit normaler, aktueller Intel/AMD Serverhardware, Intel Nics und LSI HBA Controllern. Selbst wer unter Linux oder Windows was anders nimmt ist selber schuld und dass es dann läuft ist eher sportliche Herausforderung als Vernunft.

Auch das Stromverbrauch Argument ist nicht stimmig (war ein Bug in Solaris 11.0). Platten schlafen legen ist kein Problem (bei den meisten Solaris Varianten) - aber wer braucht das kommerziell. Meine Server schlafen nicht.

Eigentlich ist Solaris&Unix@home was ganz Neues. Normalerweise ist das Big-Enterprise und das Gegenteil von home-use. Ich habe nichts gegen Linux, dennoch ist Solaris ZFS datacenter use, revolutionär und bei Linux noch Neuland.

Es ist auch nicht wie bei OSX wo kaum eine Hardware unterstützt wird, die "Desktop-Experience" dennoch am Besten ist. Es wird alles unterstützt was wichtig ist (sogar besagte Schrott Realteks). Das sollte doch reichen. (Ich bin froh, dass der sonstige Murks nicht geht)

Der Rest ist I know it, i like it, i prefer it...
Ich hatte mehrere Linux Anläufe und bin froh dass es freies Unix (BSD und Solaris) als Alternative gibt - Erst mit Solaris habe ich es beispielsweise gewagt, meine Windows Fileserver abzulösen.
 
Hi

Ich beschäftige mich schon seit mehreren Monate mit ZFS, den Vor- und Nachteilen und konnte mir noch nicht diese zwei Fragen beantworten.

1. Ist es zwingend notwendig bei ZFS ECC Ram zu verwenden? Quelle: Data integrity: the risks of not using ECC with ZFS (a study) - [H]ard|Forum

Erläuterung: ZFS hat ja viele Schutzfunktionen Checksummen etc. die vor Fehlern schützen sollen. Aber ZFS kann nicht davor schützten, wenn der RAM Fehler macht.

2. Ich habe gelesen, das man wenn man ZFS verwendet die Festplatten nicht in den Standy schicken soll. Stimmt das? Quelle: warnings [NAS4Free]

Warnings

There are lots of things you SHOULD NOT do with your NAS. While the legal ramifications of what you do with your hardware may cause you legal problems, that isn't something we plan to address. You shouldn't be doing illegal things. That said, here we go.
ZFS-related
Spin-down

It is not recommended to spin down drives that are pools or part of pools in ZFS. Periodically, drives that are part of pools that get spun down don't spin up gracefully later, and this will make the pool (in some cases) unusable, forcing you to reboot to get the pool and system running right again. So, please don't spin down ZFS pool drives. (also it wears out the hard drives faster while saving you some minor power usage)

This is most notable with rotational drives that are attached by SATA to USB adapters, and the drive is inactive long enough to be spun down by the toaster/adapter. So, using ZFS with drives attached this way is definitely not recommended.


THX

Gruß
 
zu 2)
Doch das ist möglich. Habe einen HP N40L mit 4x2 TB WD Platten und ich kann sie ohne weiteres in des Schlafmodus schicken. Ob das bei NAS4Free geht weiss ich nicht. Bei OmniOS+Napp-it-to-Go und bei OpenIndiana+Napp-It geht das.
 
Zuletzt bearbeitet:
zu 2)
Doch das ist möglich. Habe einen HP N40L mit 4x2 TB WD Platten und ich kann sie ohne weiteres in des Schlafmodus schicken. Ob das bei NAS4Free geht weiss ich nicht. Bei OmniOS+Napp-it-to-Go und bei OpenIndiana+Napp-It geht das.
Das angesprochene Problem ist nicht das Schlafenlegen, sondern das Risiko das sie nicht (rechtzeitig) wieder aufwacht oder im Falle einer externen USB ganz verschwunden ist und der Pool "unnötigt" in den degraded state geht.

Ich habe es auch seit einigen Jahren mit spindown ohne Probleme am laufen, denn der Stromverbrauch ist doch schon erheblich (bei meinen 19 Platten sind es gemessene 170W)...aber ich habe auch keine USB Disks dabei...alles fest an internen Controllern/Backplanes und mit vernünftigen Kabeln.
 
Hi

1. Ist es zwingend notwendig bei ZFS ECC Ram zu verwenden? Quelle: Data integrity: the risks of not using ECC with ZFS (a study) - [H]ard|Forum

Frage:
Ist es für ein Auto zwingend notwendig,
neben einem Sicherheitsgurt zusätzlich ABS und dann noch Airbags zu haben?

Antwort:
Für das Auto nicht, aber vielleicht für den Fahrer. Clever wäre es vielleicht sogar noch ESP draufzulegen.


Für einen Server mit oder ohne ZFS ist das genauso.
Der braucht kein ECC, der Mensch davor, dem seine Daten wichtig sind schon eher.
Genau wie Echtzeit Prüfsummen auf alle Daten, Raid oder CoW Snapshots als vorherige Versionen auf einem selbstheilenden ZFS Dateisystem.
 
Zuletzt bearbeitet:
Frage:
Ist es für ein Auto zwingend notwendig,
neben einem Sicherheitsgurt zusätzlich ABS und dann noch Airbags zu haben?

Antwort:
Für das Auto nicht, aber vielleicht für den Fahrer. Clever wäre es vielleicht sogar noch ESP draufzulegen.


Für einen Server mit oder ohne ZFS ist das genauso.
Der braucht kein ECC, der Mensch davor, dem seine Daten wichtig sind schon eher.
Genau wie Echtzeit Prüfsummen auf alle Daten, Raid oder CoW Snapshots als vorherige Versionen auf einem selbstheilenden ZFS Dateisystem.

Mit ECC-RAM potenzierst du nochmals die Datensicherheit. Ohne ECC würde die falsche Berechnung einer Checksumme eines korrekten Datenblocks im RAM zu einer Fehlermeldung an das ZFS führen und zur Verwendung des (falls vorhanden) alternativen Datenblocks, dessen dann berechnete Checksumme im korrekt arbeitenden RAM-Bereich zu einem OK führt, und der korrekte, aber falsch überprüfte Datenblock wird sinnloserweise ausgetauscht. Wenn das vereinzelt passiert und ein genügend hohes "RAID"-Level eingestellt ist, evtl. raidz2, dann ist das noch unproblematisch, passiert es häufig, wird's kritisch und langsam, und die Gefahr wächst mit steigender Betriebszeit des Servers.
 
Hallo Zusammen,

ich bin aufgrund der fehlenden Treiberunterstützung meines HP N40L und der fehlenden "Offenheit" von nas4free auf Debian Wheezy umgestiegen. Ich hab Debian ganz einfach installiert, ebenso ZFS on Linux. Hab den Pool importiert und bin echt zufrieden wie gut das geklappt hat.

Jetzt ist mir aber aufgefallen, dass ich echt miese Datentransfer Raten habe. Bevor ich auf Linux umgestiegen bin konnte ich mein Gbit Lan zuhause ohne Probleme auslasten. Jetzt ist mir aber aufgefallen, als ich eine große Datei auf den Server kopieren wollte - das die Datenrate sich so um die 20MB/s bewegt.
Daraufhin hab ich mal parallel ein TOP aufgemacht und muss feststellen das die wa immer so auf 80-90 rumdümpelt. Danach hab ich mal ein dd auf den zpool gemacht und komme auch nicht über 20mb/s - jemand ne Idee woran das liegen könnte ? Ich stehe echt auf dem Schlauch ...
 
Hallo habe mehrere Fragen zu ZFS:

Plane einen Fileserver mir zu bauen, einen Microserver von HP habe ich bereits, im Moment noch mit Windows 2012. Würde gern NAS4Free einsetzen auch aus dem Grund weil einfach schon vieles fertig ist (iTunes Server etc.). Denke FreeBSD ist für daheim vorzuziehen weil manche Software wohl für Solaris nie erscheinen wird (zB Plex Server). Daher denke ich hat man im privaten Umfeld mit FreeBSD (NAS4Free) einfach eine höhere Kompatibilität um Programme direkt da laufen zu lassen und um eine VM drum herum kommt.

Ist zumindest mein Eindruck den ich nach stundenlangem googlen so rausgefunden habe. Wer es besser weiß soll natürlich gern was dazu sagen;)

Nächste Frage ist dann wie läuft das mit der Defragmentierung in ZFS-Pools ab. Habe dazu eher wenig gefunden bis auf dass ZFS damit aufgrund des CoW wohl doch ein kleines Problem hat.

Einen ZFS Pool mit V28 sollte ich doch überall importieren können oder? Solaris, FreeBSD, Linux ?


Selbst bei einem lahmen HP Microserver bringt LZ4 compress im L2ARC SSD Lese-Cache bis zu 50% mehr Durchsatz. CPU ist also praktisch egal, siehe L2ARC Compression - illumos - illumos wiki
LZ4 gibts aber erst ab V5000 oder? Ist das Feature für daheim überhaupt von Bedeutung? Die meisten Dateien, vorallem Multimedia die am meisten Platz weg nehmen sind doch eh schon alle komprimiert.
Ich mein wo hat man als HomeUser wirklich noch Dateien die unkomprimiert sind? mp3,jpeg,mpeg2/4 ist doch alles schon komprimiert.
RAW Dateien vonner Digicam würden mir jetzt spontan einfallen nur oder vielleicht noch nen Backup vom System.
 
Zuletzt bearbeitet:
Hallo Gea,

ich habe leider immer noch Probleme beim Einsatz der Replication-Extension. Der Timeout reicht nicht aus bis zum Aufwachen des großen Storagepools.
Manchmal brechen die Jobs mit einer Fehlermeldung ab, ab und an laufen sie aber auch ohne Fehlermeldung viele Tage ohne etwas zu machen. Erst bei manuellem Abbruch der Jobs erscheinen dann die entsprechenden Fehlermeldungen. Das Snappaar ist dann leider auch zerstört, es ist dann anschließend nur noch ein Snap vorhanden, der zweite des Paares fehlt. Dummerweise hat es aber auch nicht ausgereicht, auf Quelle und Ziel die alten Snaps zu löschen um die Replication wieder zu starten, es musste das komplette Filessystem gelöscht werden.

Daher habe ich jetzt unter /var/web-gui/data/scripts/job-replicate.pl in der Zeile $timer=time() + 60; die Zeit auf 160s hochgesetzt.
Gibt es dabei noch andere negative Effekte? Das ich die Zeile bei jedem Update neu anpassen muss ist mir klar.

Gruß Millenniumpilot
 
Hallo Gea,

ich habe leider immer noch Probleme beim Einsatz der Replication-Extension. Der Timeout reicht nicht aus bis zum Aufwachen des großen Storagepools.
Manchmal brechen die Jobs mit einer Fehlermeldung ab, ab und an laufen sie aber auch ohne Fehlermeldung viele Tage ohne etwas zu machen. Erst bei manuellem Abbruch der Jobs erscheinen dann die entsprechenden Fehlermeldungen. Das Snappaar ist dann leider auch zerstört, es ist dann anschließend nur noch ein Snap vorhanden, der zweite des Paares fehlt. Dummerweise hat es aber auch nicht ausgereicht, auf Quelle und Ziel die alten Snaps zu löschen um die Replication wieder zu starten, es musste das komplette Filessystem gelöscht werden.

Daher habe ich jetzt unter /var/web-gui/data/scripts/job-replicate.pl in der Zeile $timer=time() + 60; die Zeit auf 160s hochgesetzt.
Gibt es dabei noch andere negative Effekte? Das ich die Zeile bei jedem Update neu anpassen muss ist mir klar.

Gruß Millenniumpilot

wg job restart:
Im Falle eines Fehlers gibt es einen neuen Source snap aber keinen passenden Zielsnap.
Bei einem restart wird das neueste Paar benutzt. (Der zusätzliche Quellsnap stört nicht)

Für ein komplettes resync muss das alte Ziel ZFS gelöscht oder umbenannt werden


Ansonsten "sollte" ein timout von 160s nicht stören.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh