Entscheidung zwischen UFS und ZFS

[Yamagi]

Um die vfs.read-max Frage noch zu klären. In FreeBSD 8.1-RELEASE, sys/kern/vfs_cluster.c:

  74 static int read_max = 8;
  75 SYSCTL_INT(_vfs, OID_AUTO, read_max, CTLFLAG_RW, &read_max, 0,
  76     "Cluster read-ahead max block count");

Also ist die Standardeinstellung 8. Die letzte Änderung war am "Thu Mar 13 05:49:09 2003 UTC" durch jeff@, er hat den wert von 64 auf 8 gesenkt. Es war SVN-Revision r112174. Damals wurde auch gleich das sysctl eingefügt:

- Regularize variable usage in cluster_read().
 - Issue the io that we will later block on prior to doing cluster read ahead
   so that it is more likely to be ready when we block.
 - Loop issuing clustered reads until we've exhausted the seq count supplied
   by the file system.
 - Use a sysctl tunable "vfs.read_max" to determine the maximum number of
   blocks that we'll read ahead.

Wenn da andere Werte als 8 drin stehen, muss sie jemand setzen. Ich habe jetzt aber auf die schnell nichts gefunden, wo es passieren könnte. Mein Tipp wäre ein Controller-Treiber.

EDIT: Und auch in -CURRENT (und damit 8-STABLE) steht da als Standard 8 drin.

 

[Columbo0815]

Vor allem zwei Sachen. Einmal "vfs.read_max=32". Damit liest er bei jedem Zugriff immer 32 Blöcke ein.

"vfs.ufs.dirhash_maxmem=134217728". Wesentlich mehr Speicher für Dirhashes.

Ich habe von diesem ganzen Technikkram keine Ahnung. Ich habe hier ein FreeBSD-8.1/amd64, das 2 Sata-Platten hat. Kopiere ich von der einen auf die andere habe ich 100 MB/sec, was ich ganz gut finde. Was ich nicht gut finde ist, dass das System so dermaßen in die Knie geht, dass es sich anfühlt wie ein System bei einem Load von 5. Bevor ich nun rumschraube, können diese einstellungen besserung bringen? Also.. Rein von der Theorie her

 

[Yamagi]

Nein, nicht wirklich. Dieses "in die Knie gehen" ist genau das, was Phoronix Benchmarks zeigen. FreeBSD mag es schlicht nicht, wenn viel Last auf den Platten liegt. Passiert das ganze auch noch parallel auf verschiedenen Laufwerken, wird es eklig. Der große Unterschied zwischen 7 und 8 ist, dass FreeBSD 7 faktisch tot gewesen wäre, FreeBSD 8 aber noch nutzbar bleibt. Unter FreeBSD 7 konnte man auch schon bei recht simplen Workloads Totalblockaden beobachten. Aber mal davon abgesehen... Ein Einbruch bis runter zu ruckelnder Maus ist schon ungewöhnlich und sollte nicht sein. Sind die Platten oder eine der Platten zufällig verschlüsselt?

 

[Columbo0815]

Die Maus ruckelt nicht. Wenn ich mich richtig erinnere, tat sie das unter 7.2 tatsächlich noch.

Es dauert nur ein paar Sekunden, wenn ich irgend etwas auswähle oder ein Programm starte (ok, liegt auf der selben Platte wie die Lesezugriffe). Es reagiert auch beim Wechsel von Programmen träge. Aber ruckeln tut die Maus nicht.

Nein, eine Festplatte ist auf diesem System hier nicht verschlüsselt. Auf dem anderen 8.1-rechner (i386) ist eine verschlüsselt. Dort allerdings dank padlock praktisch unbemerkt.

 

[Yamagi]

Diese leichte Zähheit beim Programmwechsel und jedem Plattenzugriff ist normal. Dafür / Dagegen gibt es neu in FreeBSD 8.1 "gsched", eine GEOM-Klasse die konkurrierende Zugriffe verschiedener Nutzer auf die Platte balanciert. Die soll genau diese Zähheit, da ein Programm verhungert während ein anderes wunderbar endlos rödelt, verhindern. Selbst damit gemacht habe ich aber noch nichts. Steht auf meiner Liste aber recht weit oben.

 

[solarix]

I
ZFS hat die großen Vorteile, dass es wirklich geniale Snapshots hat, eingebautes Volumenmanagement und das es intern die Daten auf Konsistenz prüfen kann. Ein fsck(8) ist nicht mehr nötig, das Dateisystem ist immer atomar Konsistent. Der Preis sind vergleichsweise großer Ressourcenverbrauch und auf Einzelplatten (kein RAID) nur mittelprächtige Performance. ZFS ist daher eher für große Fileserver geeignet, sowie für Workstations, die von seinen Funktionen profitieren können. Meine Entwicklerkiste hat z.B. ZFS, da ich damit mein FreeBSD munter hin und her upgraden kann und jederzeit einfach auf spätere Snapshots zurück.

Da muss ich Dir widersprechen. Vor allem das mit dem FSCK.
Der Scrub der von ZFS durchgefuehrt wird ist im Prinzip ein FSCK nur das wir keine Eingriffsmoeglichkeit haben und verreckte Zpools hab ich auch schon mehr als genug gesehen. Bei Bedarf kann ich die Links zu den Bugs auch raussuchen.

Vor allem hat ZFS die Veranlagung den Pool zu blocken wenn es der Meinung ist das der Pool corrupt ist. Dann kannst Du nur noch dein hoffentlich aktuelles Backup nehmen, den Pool zerstoeren, neu anlegen und restoren.

Vor allem Da Du keine Eingriffsmoeglichkeit hast kann ein geblockter Pool auch nicht gefixt werden. Im Zweifelsfall bleibt Dir nur den Pool abzuhängen (wenn es überhaupt noch geht) den ZDB zu starten und Die Daten vom Uberblock rauszulesen.

ZFS hat auch ein paar ganz ueble Bags wir haben festgestellt das es unter bestimmten Umständen dazu kommen das ZFS sich bei der Bytegroeße verrechnet. Grade wenn Du RAW Devices im Zpool drin hast und Du Datenbank Chunks anlegst stimmt die Dateilänge zwischen ZFS und der Datenbank Deiner Wahl, in unserem Fall Informix nicht ueberein. 2GB sind nicht gleich 2GB. ZFS berechnet die GBs zu kurz und wenn Die Informix, oder auch die Oracle reinschreibt, fliegst Du auf die Nase. Was wiederum zum blockieren des Pools fuehrt.

Wie Du auch richtig sagst, das bei großer Auslastung des Pools die Lese und Schreibgeschwindigkeit zusammen bricht, kann ich voll und ganz bestätigen.

Von Sun ZFS Leuten gibt es selbst die Aussage das ein Pool nicht mehr als 85 Prozent Auslastung verträgt, weil ZFS dann unsäglich langsam wird. Ab 90 Prozent Disk Usage wird es unerträglich langsam. Wir konnten dieses Verhalten mehrfach reproduzieren.

Das Dateisystem ist eben doch noch sehr jung.

 

[Yamagi]

Ja, das stimmt alles schon. In deiner Liste fehlt allerdings noch mein Lieblingsbug. Wenn sich die Reihenfolge der Platten im System ändert, weil der Controller zum Beispiel nach einem Hotplug meint sie neu ordnen zu müssen, geschehen sehr unangenehme Dinge bis hin zum zerdepperten Pool. Einziger Workaround sind da Disklabels...

Was ich oben eigentlich sagen wollte war, dass ZFS zumindest theoretisch eben ein sehr sicheres und konsistentes Dateisystem ist. Das es nicht immer stimmt, liegt halt an den noch vorhandenen Bugs. Ich persönlich tendiere inzwischen dazu ZFS ein "Automagie-Problem" zu unterstellen. Das Ding vertraut sich und seiner Pseudointelligenz einfach viel zu sehr, hält den Nutzer daher für zu dumm und gibt ihm keine Eingreifsmöglichkeiten. Das ist nicht nur der berüchtigte Scrub, sondern auch die wirklich teils sehr dumm gelöste Bindung eines Pools an ein System (was man zum Glück inzwischen per Gewalt umgehen kann) und eben das ZFS meint, sein eigenes Disk-Management machen zu müssen.

 

[solarix]

Ja, das stimmt alles schon. In deiner Liste fehlt allerdings noch mein Lieblingsbug. Wenn sich die Reihenfolge der Platten im System ändert, weil der Controller zum Beispiel nach einem Hotplug meint sie neu ordnen zu müssen, geschehen sehr unangenehme Dinge bis hin zum zerdepperten Pool. Einziger Workaround sind da Disklabels...

Was ich oben eigentlich sagen wollte war, dass ZFS zumindest theoretisch eben ein sehr sicheres und konsistentes Dateisystem ist. Das es nicht immer stimmt, liegt halt an den noch vorhandenen Bugs.

Oh ja und davon gibts reichlich.

Ein richtig uebler Bug, ist z.B. "Double Import"
Kommt aber unter FreeBSD meines Wissens nicht vor.

Ich persönlich tendiere inzwischen dazu ZFS ein "Automagie-Problem" zu unterstellen. Das Ding vertraut sich und seiner Pseudointelligenz einfach viel zu sehr, hält den Nutzer daher für zu dumm und gibt ihm keine Eingreifsmöglichkeiten. Das ist nicht nur der berüchtigte Scrub, sondern auch die wirklich teils sehr dumm gelöste Bindung eines Pools an ein System (was man zum Glück inzwischen per Gewalt umgehen kann) und eben das ZFS meint, sein eigenes Disk-Management machen zu müssen.

Ja das mit der "Automagie" kann sogar einen dicken Storage Hobel in die Knie zwingen.
Besonders wenn Du keinen simplen JBOD ohne Eigenintelligenz im Einsatz hast, sondern großes Geschuetz wie z.B. HDS Tagmastore. Die "Eigenintelligenz" von HDS und ZFS koennen sich gegenseitig zu Tode cachen.

 

[Yamagi]

So, vfs.read_max wurde nun erhöht:

  Date: Sat, 7 Aug 2010 20:30:10                                                   
  From: Ivan Voras <ivoras@FreeBSD.org>                                            
  To: src-committers@freebsd.org, svn-src-all@freebsd.org,                         
      svn-src-head@freebsd.org                                                     
  Subject: svn commit: r211031 - head/sys/kern                                     
                                                                                   
  Author: ivoras                                                                   
  Date: Sat Aug  7 18:30:10 2010                                                   
  New Revision: 211031                                                             
  URL: http://svn.freebsd.org/changeset/base/211031                                
                                                                                   
  Log:                                                                             
    To help with sequential read UFS performance on modern systems, increase       
    the vfs.read_max default. For most systems this means going from 128 KiB       
    to 256 KiB, which is still very conservative and lower than what most          
    other operating systems use, but as a sane default should not                  
    interfere much with existing systems.                                          
                                                                                   
    For systems with RAID volumes and/or virtualization envirnments, where         
    read performance is very important, increasing this sysctl tunable to 32       
    or even more will demonstratively yield additional performance benefits.       
                                                                                   
    If MAXPHYS ever gets bumped up, it will probably be a good idea to slave       
    read_max to it.                                                                
                                                                                   
  Modified:                                                                        
    head/sys/kern/vfs_cluster.c                                                    
                                                                                   
  Modified: head/sys/kern/vfs_cluster.c                                            
  ==============================================================================   
  --- head/sys/kern/vfs_cluster.c       Sat Aug  7 17:57:58 2010        (r211030)  
  +++ head/sys/kern/vfs_cluster.c       Sat Aug  7 18:30:10 2010        (r211031)  
  @@ -71,7 +71,7 @@ static int write_behind = 1;                                   
   SYSCTL_INT(_vfs, OID_AUTO, write_behind, CTLFLAG_RW, &write_behind, 0,          
       "Cluster write-behind; 0: disable, 1: enable, 2: backed off");              
                                                                                   
  -static int read_max = 8;                                                        
  +static int read_max = 16;                                                       
   SYSCTL_INT(_vfs, OID_AUTO, read_max, CTLFLAG_RW, &read_max, 0,                  
       "Cluster read-ahead max block count");

 

[h^2]

AHHH, ich habe jetzt ZFS und die Performance ist grauenhaft

Ich kriege schreiben 13MiB/s auf die Platte, WTF? Das ist eine WD20EADS, also Energiespar-FOO, aber auf die WD10EADS mit UFS kriege ich 70MiB/s schreibend. Und das obwohl da noch aes-256 drunter steckt (unter dem ZFS nur aes-128).

Bitte sagt mir nicht, dass das normal ist. Da kann ich mir Gbit ja gleich sparen und auf 1Mbit-Coaxial downgraden :|

 

[Crest]

Die WD20EADS sollte eine Platte mit 4KiB Sektoren seinen. Kann es sein das du das Alignment falsch hast? Sollte dem so sein ist jeder Schreibvorgang für die Firmware der Platte ein Read-Modify-Write das würde die Performance erklären. Mein kleines Spielzeug von Heimserver/router mit 3 ollen SATA Platten als RAID-Z1 und nem 1 x 2,7GHz Sempron 140 schafft >120MiB/s schreiben und >170 MiB/s lesend. Demnach ist das nicht normal.

 

[MrMarv]

[...]Mein kleines Spielzeug von Heimserver/router mit 3 ollen SATA Platten als RAID-Z1 und nem 1 x 2,7GHz Sempron 140 schafft >120MiB/s schreiben und >170 MiB/s lesend. Demnach ist das nicht normal.

Wie messt ihr das, bzw wie hast du das gemessen?
Nur damit ich mal meine Daten damit vergleichen kann, hab ein ähnliches Setup hier.
Danke!

Cheers!

 

[h^2]

Die WD20EADS sollte eine Platte mit 4KiB Sektoren seinen. Kann es sein das du das Alignment falsch hast? Sollte dem so sein ist jeder Schreibvorgang für die Firmware der Platte ein Read-Modify-Write das würde die Performance erklären. Mein kleines Spielzeug von Heimserver/router mit 3 ollen SATA Platten als RAID-Z1 und nem 1 x 2,7GHz Sempron 140 schafft >120MiB/s schreiben und >170 MiB/s lesend. Demnach ist das nicht normal.

Ne, die WD20EADS ist die mit normalen Sektoren. Die mit den 4KB Sektoren ist die WD20EARS, habe ich extra drauf geachtet.

Wie messt ihr das, bzw wie hast du das gemessen?
Nur damit ich mal meine Daten damit vergleichen kann, hab ein ähnliches Setup hier.

Also ich hatte schlechte Ergebnisse mit rsync, danach habe ich dann mit sdd versucht daten zu schreiben (if=/dev/zero) oder zu lesen (of=/dev/zero). Das ist vielleicht nicht ganz representativ, aber die starke Abweichung ist imo trotzdem aussagekfräftig.

P.S: sorry für den Tonfall oben, war einfach relativ (negativ) überrascht.

edit: beim of ist es natürlich /dev/null

 

[Kamikaze]

Ich kriege schreiben 13MiB/s auf die Platte, WTF? Das ist eine WD20EADS, also Energiespar-FOO, aber auf die WD10EADS mit UFS kriege ich 70MiB/s schreibend. Und das obwohl da noch aes-256 drunter steckt (unter dem ZFS nur aes-128).

Das ist jetzt etwas am Thema vorbei, aber nach aktuellem Wissensstand ist aes-256 weniger sicher als aes-128, weil mehr Angriffe bekannt sind, die das Verfahren schwächen, was nicht heißt, dass aes-256 schon gebrochen ist.

Auch ist aes-256 prinzipiell schneller, weil man weniger als den doppelten Aufwand wie bei aes-128 treibt um einen doppelt so großen Block zu verschlüsseln.

3DES zum Beispiel gilt immer noch als sicherer als die beiden anderen Verfahren. Jedoch ist es in Software einfach nur *rschlahm, da es für Hardware-Anwendungen gedacht ist.

 

[olhe]

And for new applications I suggest that people don't use AES-256. AES-128 provides more than enough security margin for the forseeable future. But if you're already using AES-256, there's no reason to change.

Bruce Schneier

 

[h^2]

Jo, war mir bewusst, deswegen halt auch jetzt aes-128 statt aes-256. Trotzdem würde ich gerne wissen ob es normal ist, dass unter ZFS die Schreibgeschwindigkeit so dramatisch einbricht.

Ich habe jetzt in dem zpool mal ein UFS erzeugt, auf das ich auch nur so langsam schreiben kann. Ich weiß aber nicht ob das zu erwarten wäre, weils ja im zpool liegt oder ob das gegen die hardware spricht. Leider belegt der pool schon die ganze Platte und ich kann nicht ein "echtes" UFS erzeugen. Da der zpool schon relativ stark unterteil und konfiguriert wurde, würde ich den ungern löschen müssen um das Ganze zu testen…

 

[Crest]

Das ist jetzt etwas am Thema vorbei, aber nach aktuellem Wissensstand ist aes-256 weniger sicher als aes-128, weil mehr Angriffe bekannt sind, die das Verfahren schwächen, was nicht heißt, dass aes-256 schon gebrochen ist.

Deine Information ist falsch/unvollständig. Es gibt theoretische Angriffe auf AES-256 die möglicherweise schneller als 2^256 sind jedoch nicht schneller als 2^128.

Auch ist aes-256 prinzipiell schneller, weil man weniger als den doppelten Aufwand wie bei aes-128 treibt um einen doppelt so großen Block zu verschlüsseln.

Die Blockgröße ist bei AES unabhängig von der Schlüssellänge 128 Bit. Rjindael ist für 128, 192 und 256 Bit Blöcke spezifiziert. Nur die Varianten mit 128 Bit Blockgröße und 128, 192 oder 256 Bit Schlüssel sind als AES standartisiert.
Die Anzahl der Runden pro Block ist bei AES abhängig von der Schlüssellänge. 10 Runden für 128 Bit Schlüssel, 12 für 192 Bit Schlüssel, 14 für 256 Bit Schlüssel. Somit ist AES-256 in Software i.d.R. ca. 40% langsamer als AES-128.

3DES zum Beispiel gilt immer noch als sicherer als die beiden anderen Verfahren. Jedoch ist es in Software einfach nur *rschlahm, da es für Hardware-Anwendungen gedacht ist.

Dem muss ich leider widersprechen. Ersten lässt sich (3)DES per Bitslicing (relativ) schnell implementieren, wenn die Anwendung es zulässt, und zweitens ist es unsicherer als AES nach heutigem Kenntnissstand. 3DES hat nur eine effektive Schlüssellänge von 112 Bit und muss aufgrund seiner Blockgröße von 64 Bit sehr vorsichtig eingesetzt werden bei den Datenmengen moderner Festplatten.

 

[waki87]

Ich habe jetzt in dem zpool mal ein UFS erzeugt, auf das ich auch nur so langsam schreiben kann. Ich weiß aber nicht ob das zu erwarten wäre, weils ja im zpool liegt oder ob das gegen die hardware spricht. Leider belegt der pool schon die ganze Platte und ich kann nicht ein "echtes" UFS erzeugen. Da der zpool schon relativ stark unterteil und konfiguriert wurde, würde ich den ungern löschen müssen um das Ganze zu testen…

Nein, es ist definitiv nicht normal. Ich habe ein RAID-Z Setup mit Geli AES-256 drunter und bekomme bei »naiven« dd-Benchmarks um die 100MB/s. Woran es liegen könnte (wenn es nicht doch die Sektorgröße der Platte ist – ich würde mal überprüfen, ob es nicht doch eine der »Advanced Format«-Dinger ist): Die Blockgröße eines Geli-Providers (glaube ich) per default 4KiB. Je nachdem, wie du die Performance testest, kann das Auswirkungen haben. Von daher wäre es wichtig, den genauen Befehl zu kennen, mit dem du gearbeitet hast.

Außerdem wichtig: Wie viel RAM hat die Kiste? Sind andere Filesysteme als ZFS gemountet? Ist prefetch eingeschaltet? Hast du sonst irgendwelches Tuning vorgenommen?

 

[Kamikaze]

Dem muss ich leider widersprechen. Ersten lässt sich (3)DES per Bitslicing (relativ) schnell implementieren, wenn die Anwendung es zulässt, und zweitens ist es unsicherer als AES nach heutigem Kenntnissstand. 3DES hat nur eine effektive Schlüssellänge von 112 Bit und muss aufgrund seiner Blockgröße von 64 Bit sehr vorsichtig eingesetzt werden bei den Datenmengen moderner Festplatten.

Nach meinem Wissenstand ist AES-256 mit unter 2^100 (im meinem Kopf spukt 2^96 herum, ich müsste das noch mal nachlesen um sicher zu sein) zu knacken und damit schwächer als 3DES. Ich habe noch nie von einem Verfahren gehört, dass DES schwächt, das einzige Problem ist die kurze Schlüssellänge von 56Bit, die man heutzutage mit vertretbarem Aufwand per Brute-Force knacken kann.

Die 112Bit von 3DES sind entgegen den AES Schlüsseln meines Wissens nicht mit einem einzigen Angriffsverfahren angekratzt. So alt wie das Verfahren ist, glaube ich auch nicht, dass das jemals passiert. Es sei denn es kommen ganz neue Erkenntnisse in der Mathematik, die die Kryptographie in den Grundfesten erschüttern.

Allerdings erkauft man sich mit 3DES, den doppelten Verschlüsselungsgrad mit dem 3-fachen Rechenaufwand gegenüber DES.

Die ganze Bit-shifterei in DES kann man in Hardware supereffizient machen, aber in Software sind dafür eine Menge Operationen nötig, während AES komplett aus simplen Integer Operationen besteht und vollständig als polynomiales Gleichungssystem darstellbar ist. Eben jene Operationen auf die handelsübliche CPUs im großen und ganzen optimiert sind.

 

[Crest]

Passende Betriebsmodi vorrausgesetzt bietet Disk I/O die nötige Parallität um effektiv Bitslicing zu verwenden. Details siehe Paper zum Thema.

 

[h^2]

Nein, es ist definitiv nicht normal. Ich habe ein RAID-Z Setup mit Geli AES-256 drunter und bekomme bei »naiven« dd-Benchmarks um die 100MB/s.

Nagut, dass ist aber auch ein RaidZ, ich habe eine einzelne Platte.

Woran es liegen könnte (wenn es nicht doch die Sektorgröße der Platte ist – ich würde mal überprüfen, ob es nicht doch eine der »Advanced Format«-Dinger ist):

Ist es nicht!

Die Blockgröße eines Geli-Providers (glaube ich) per default 4KiB. Je nachdem, wie du die Performance testest, kann das Auswirkungen haben. Von daher wäre es wichtig, den genauen Befehl zu kennen, mit dem du gearbeitet hast.

Ein Standard "rsync --progress" einer 4GiB Datei erläutert das ganze schon sehr gut, da bekomme ich 12MiB schreibend auf die WD20EADS und 29MiB schreibend auf die WD10EADS -- jeweils von der einen auf die andere Platte.

Mit

 sdd if=/dev/zero of=/datei/auf/jeweils/einerplatte bs=512 count=1000000 -t

fürs schreiben und

 sdd if=/datei/auf/jeweils/einerplatte of=/dev/null -t

fürs lesen; und dann warten oder SIGINFO habe ich gemessen. Da bekomme ich
WD20EADS: lesend 29MiB, schreibend 13MiB
WD10EADS: lesend 32MiB, schreibend 62MiB.

Das deckt sich mit den praktischen Erfahrungen mit rsync oben (die Schreibrate auf die WD10EADS ist da durch die Leserate der WD20EADS limitiert). DIe geli-Sectorsize auf beiden Providern ist 4KiB.

Wenn ich die die beim sdd bs auch auf 4KiB stelle, bekomme ich leicht unterschiedliche Ergebnisse, die aber dieselbe Tendenz aufweisen:
WD20EADS: lesend 35MiB, schreibend 21MiB
WD10EADS: lesend 35MiB, schreibend 75MiB.

Außerdem wichtig: Wie viel RAM hat die Kiste?

4GiB

Sind andere Filesysteme als ZFS gemountet?

Ja, / ist ufs auf ner CF-Kart. Außerdem halt gerade noch die UFS von der WD10EADS.

Ist prefetch eingeschaltet? Hast du sonst irgendwelches Tuning vorgenommen?

Kein prefetch, kein tuning.

 

[waki87]

Ein Standard "rsync --progress" einer 4GiB Datei erläutert das ganze schon sehr gut, da bekomme ich 12MiB schreibend auf die WD20EADS und 29MiB schreibend auf die WD10EADS -- jeweils von der einen auf die andere Platte.

Damit testest du natürlich effektiv nur die Schreib-/Leserate der WD20EADS, da diese offensichtlich die langsamere der beiden Platten ist.

Zumindest die abnormal langsame Schreibgeschwindigkeit muß an der WD20EADS liegen. Mach für die doch mal ein Benchmark mit diskinfo(8). Bei 4GB RAM kannst du auch, wenn du nicht gerade für andere Zwecke sehr viel Speicher brauchst, prefetch einschalten. Vielleicht hilft’s, vielleicht nicht.

Wenn es an ZFS liegt, beobachte mittels top mal den Speicherverbrauch. Hast du genügend »Free«-Speicher? »Inactive«-Speicher wird von ZFS nicht genutzt, daher kann es zu erheblichen Engpässen kommen, wenn dieser nicht freigegeben wird. Das kann unter anderem vor allem dann passieren, wenn andere Filesysteme ihn im Voraus allozieren (daher die Frage). Darüber gab es vor einiger Zeit auch mal Diskussionen auf den Mailinglisten. Man kann dem durch das Einschalten von prefetch oder das Erhöhen von vfs.zfs.arc_min weitgehend entgegenwirken.

Die Skripte arc_summary.pl und arcstat.pl sind bei der Beobachtung der arcsize von großem Nutzen.

 

[h^2]

Damit testest du natürlich effektiv nur die Schreib-/Leserate der WD20EADS, da diese offensichtlich die langsamere der beiden Platten ist.

Zumindest die abnormal langsame Schreibgeschwindigkeit muß an der WD20EADS liegen. Mach für die doch mal ein Benchmark mit diskinfo(8).

Hm, interessant, WD20EADS:

# diskinfo -t /dev/ad4
/dev/ad4
        512             # sectorsize
        2000398934016   # mediasize in bytes (1.8T)
        3907029168      # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        3876021         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        WD-WCAVY5108310 # Disk ident.

Seek times:
        Full stroke:      250 iter in   8.530155 sec =   34.121 msec
        Half stroke:      250 iter in   5.848538 sec =   23.394 msec
        Quarter stroke:   500 iter in   9.727978 sec =   19.456 msec
        Short forward:    400 iter in   2.789740 sec =    6.974 msec
        Short backward:   400 iter in   1.757052 sec =    4.393 msec
        Seq outer:       2048 iter in   0.333490 sec =    0.163 msec
        Seq inner:       2048 iter in   0.289034 sec =    0.141 msec
Transfer rates:
        outside:       102400 kbytes in   1.095377 sec =    93484 kbytes/sec
        middle:        102400 kbytes in   1.203486 sec =    85086 kbytes/sec
        inside:        102400 kbytes in   2.072939 sec =    49398 kbytes/sec

WD10EADS:

# diskinfo -t /dev/ad6
/dev/ad6
        512             # sectorsize
        1000204886016   # mediasize in bytes (932G)
        1953525168      # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        1938021         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        WD-WCAU45893676 # Disk ident.

Seek times:
        Full stroke:      250 iter in   5.681830 sec =   22.727 msec
        Half stroke:      250 iter in   3.982201 sec =   15.929 msec
        Quarter stroke:   500 iter in   6.573410 sec =   13.147 msec
        Short forward:    400 iter in   1.643164 sec =    4.108 msec
        Short backward:   400 iter in   3.514278 sec =    8.786 msec
        Seq outer:       2048 iter in   0.509685 sec =    0.249 msec
        Seq inner:       2048 iter in   0.301942 sec =    0.147 msec
Transfer rates:
        outside:       102400 kbytes in   1.113632 sec =    91951 kbytes/sec
        middle:        102400 kbytes in   1.292899 sec =    79202 kbytes/sec
        inside:        102400 kbytes in   2.251682 sec =    45477 kbytes/sec

Sieht also ziemlich gleich aus…

Bei 4GB RAM kannst du auch, wenn du nicht gerade für andere Zwecke sehr viel Speicher brauchst, prefetch einschalten. Vielleicht hilft’s, vielleicht nicht.

Wenn es an ZFS liegt, beobachte mittels top mal den Speicherverbrauch. Hast du genügend »Free«-Speicher? »Inactive«-Speicher wird von ZFS nicht genutzt, daher kann es zu erheblichen Engpässen kommen, wenn dieser nicht freigegeben wird. Das kann unter anderem vor allem dann passieren, wenn andere Filesysteme ihn im Voraus allozieren (daher die Frage). Darüber gab es vor einiger Zeit auch mal Diskussionen auf den Mailinglisten. Man kann dem durch das Einschalten von prefetch oder das Erhöhen von vfs.zfs.arc_min weitgehend entgegenwirken.

Dem ist allerdings so

 Mem: 26M Active, 2993M Inact, 677M Wired, 87M Cache, 405M Buf, 30M Free

Also ZFS kommt nicht an die inaktiven dran? Ich werde mal prefetch einschalten. Was ist ein sinnvoller Wert für vfs.zfs.arc_min ? Das steht hier auf 104152320

Die Skripte arc_summary.pl und arcstat.pl sind bei der Beobachtung der arcsize von großem Nutzen.

Schau ich mir mal an.

Danke

 

[waki87]

Was ist ein sinnvoller Wert für vfs.zfs.arc_min ? Das steht hier auf 104152320

Sollte mit eingeschaltetem prefetch eigentlich unnötig sein, aber du kannst es ja mal auf ~300MiB setzen und schauen, was passiert.

 

[h^2]

Also ich habe prefetch eingeschaltet, arc_min verfierfacht und die anderen ufs-dateisysteme nicht gemountet.

SIehe da, ich kriege mit sdd und bs=512 eine Schreibrate von 33MiB/s und mit bs=4K eine Schreibrate von 59MiB/s. Das später die anderen Platte nicht mehr im System sein wird, macht das schonmal Hoffnung.

Bezüglich der Blocksize, bin ich schon etwas überrascht. Schlägt sich das auch beim normalen Benutzen, Kopieren etc wieder? Bringt es etwas $BLOCKSIZE auf 4K zu setzen? Wie läuft das ab, wenn Leute per NFS schreiben. Wird da die in der Umgebung des Client gesetzte BLOCKSIZE verwendet oder kann man das Serverseitig irgendwie einstellen?