Autor: chris

UBNT NanoStation

Im Rahmen anderer Spielerein hab ich mich auch mal an das Thema Richt-WLan gewagt.

Da ich schon viel UBNT Gear im Einsatz habe, viel die Wahl schnell auf die NanoStation 5AC Loco:

  • 5GHz AC
  • 13 dBi
  • bis zu 450+ Mbps
  • klein & kompakt
  • Outdoorgeeignet
  • Mobile App easy Setup

Erster Testaufbau Wohnzimmer – Küche lief nach paar Konfigurationsproblemen meinerseits sehr gut, danach zogen beide AP’s an ihre neuen Ziele.

Anfangs hab ich gar keine Verbindung aufgebaut bekommen, trotz einer im Verhältniss kurzen Distanz. Leider ist das 5GHz sehr sehr anfällig für Wände und andere Hindernisse, nach einigem Umplazierungen bin ich jetzt bei einem schon mal akzeptablen Zwischenergebniss:

Am Wochenende werde ich mal schauen, wie weit es sich noch an anderer Position verbesser lässt, aktuell längen beide noch nicht optimal. Gut beim linken zu erkennen, der 2te Pegel (horizontale Achse) ist noch sehr begrenzt…

Fazit: Geile Sache, die Software und Hardware macht Spaß und ist gut zu finanzieren. Kann ich weiter Empfehlen.

btrfs – Ein Teilerfolg

Ich habe mich schon längere Zeit nach einer dynamischen Alternative zum bisher primär von mir eingesetzten ZFS umgeschaut, da mir die physischen Platten hier zu statisch zugeordnet sind.

Was heißt das im Detail? Ich hatte bisher ein Pool aus 3x (3x 3TB Platte im Z1), also 18TB Netto. Der Plan für die Zukunft war dann, die Platten durch größere auszutauschen und im Idealfall sogar weniger Spindeln zu benutzen.

Hier kommt das Problem: Es ist nicht möglich, einen der Z1 Verbünde zu entfernen oder um Platten zu vergrößern / verkleinern, es lassen sich lediglich Platten (durch größere) 1:1 tauschen oder weitere Verbünde in den Gesamtpool aufzunehmen.

Schöner macht es CEPH, was ich mir als erstes angesehen habe: Dynamisch Platten rein oder raus, unterschiedliche Größen, alles kein Thema. Das definierte Level an Verfügbarkeit wird aufrecht erhalten.

Nachteil bei CEPH: Es ist auch einen Aufbau über Systemgrenzen hinweg ausgelegt, wenn auch anders realisierbar, und der Einsatz von Erasure Coding, wie im Raid5, ist nicht ganz trivial.

Andere Alternative: BTRFS

Das System ist wie ZFS ein CoW Dateisystem, deckt meine Anforderungen ab und inzwischen ist der Raid5 Code für meine Ansprüche an Verfügbarkeit ausreichend stabil. Für alles andere gibt es ein Backup *räusper*.

Aktuelle fahre ich jetzt 4x 8TB im Raid5.

Leider gibt es hier aber ein paar Einschränkungen, die mir im Daily Use gegenüber ZFS fehlen:

  • Die Größe von Snapshots lässt sich nicht „elegant“ anzeigen
  • Quotas ziehen sehr massiv an der Performance, sehr sehr massiv!!!
  • „Viele“ Snapshots ziehen ebenfalls viel Performance. Was als „viele“ definiert wird? Keine Ahnung…
  • SSD Caching Tier

Ich werde dem Dateisystem trotzdem noch etwas Zeit geben, wie sich gerade zeigt ist der Support von Samba zu btrfs mittels vfs ganz gut (Shadow Copy, Server Side Copy Offload).

Es wird in ein paar Wochen bestimmt nochmal ein Feedback von mir kommen.

Intel CPU und P-State

Ich hab etliche Zeit damit verbraucht, herauszufinden, warum der i3-2120 in meinem Fileserver nicht tiefer als C1E im P-State geht.

Heute bin ich eher durch Zufall auf des Rätsels Lösung gekommen:

https://bugzilla.kernel.org/show_bug.cgi?id=77361

Jesse Brandeburg 2014-06-04 21:51:54 UTC
I believe this is by design, the e1000e hardware has issues with jumbo frame reception if the processor enters a long latency sleep state.  Jumbo frames require the cpu to wake up and handle the packet reasonably fast, which is why the code is like it is.

e1000e is calling kernel interfaces to implement the C-state limits.

In meinem Filer wird auch der e1000e Treiber genutzt, und bisher waren Jumboframes aktiviert. Abgeschaltet, Reboot, C6… Dabei wollte ich gerade schon Testweise mal von 4 auf 2 Ram-Dimms gehen. 😀

Im parallel laufenden Hypervisor kommt „zum Glück“ eine andere Nic zum Einsatz, ob das jetzt mit der Realtek allerdings wirklich besser ist lasse ich mal  dahin gestellt.

Manches mal ist es gar nicht so einfach, des Rätsels Lösung zu finden, nur nie aufgeben.