Ja, ich bin verwöhnt. Timemachine am Mac funktioniert wunderbar. Fast schon Science Fiction (bezogen auch auf das Restore Menü)…

Ich habe mir das Backup auf meiner externen Festplatte ein bisschen genauer angesehen und bin zu dem Entschluss gekommen, naja soviel Zauberrei wurde nun auch nicht vollbracht. Ich fing an mich weiter damit zu beschäftigen und peinlicherweise bin ich als Linuxfan häufig über rsync gestossen, habe es aber nie wirklich verwendet. Bis heute…

…und ich bin begeistert! Wie Timemachine ohne Gui, geil scriptbar, transparent, remote (sogar via ssh!). Wenn ich über die Flexibilität nachdenke, fast unglaublich.

Wenn ich jetzt noch genau darüber nachdenke, dass rsync nicht wirklich etwas Neues ist (stark untertrieben), kann ich im Endeffekt nur JEDEM raten, sich mit dem Thema genauer auseinanderzusetzten.

Anbei zwei kurze Beispiele:

• Lokales syncen

rsync -a SOURCE DESTINATION

• Remote syncen verschlüsselt (SSH)

rsync -e ssh -avz SOURCE USER@HOST:DESTINATION

Viel Spass beim Experementieren!

Gerade Vordiplomsarbeit hinter mich gebracht und dabei ganz frisch mit tex begonnen. Ich wollte mich schon seid Längerem in LaTeX einarbeiten, das war die perfekte Gelegenheit.

Fazit: Tex ist genial, jedoch sollte man sich ein bisschen mit Zeichensätzen auseinandersetzen, wenn man nicht alleine und nicht am gleichen Betriebsystem arbeitet.

Auf meiner Workstation habe ich Ubuntu 9.04, da benützte ich Kile. Wirklich phantastisch, super performant und komfortabel, leider nicht ganz stabil. In Kombination mit Okular wirklich sehr gut.

Zuhause, verwende ich TexShop auf einem iMac unter 10.5. Bisschen weniger komfortabel, jedoch deutlich robuster und schönes debuggen möglich. Allerdings dauert das Rendern deutlich länger.

Zusätzlich habe ich .tex Files auch von Windows Rechner bekommen.

Fakt ist, UTF-8 (unicode) klappte am Besten. Wichtig ist, dass das Dokument auch einmalig in diesem Zeichensatz gespeichert werden muss, bevor es übertragen wird. Zusätzlich hilft es, das .tex Dokument irgendwie binär zu übertragen (tarball machen oder zip), damit der Zeichensatz nicht konvertiert wird.

Nach den typischen Anfangschwierigkeiten, gab es anschließend keine Formatierungsprobleme mehr! Ich werde LaTeX, nach diesem Versuch, auch für die Diplomarbeit benützen!

Wahnsinn, locate in Verbindung mit einer For Schleife in der Shell ist unglaublich mächtig. Sogar fast schon kreativ!

Zuerst mit updatedb meine .locate Struktur aktualisieren. 

Dann wirds ein Einzeiler, der sehr flexibel ist. Das Beste: Durch die Verwendung von locate funktioniert der Befehl von jeglicher Position. 

for i in `locate Datentyp | grep Suchbegriff `; do cp `echo $i` /Zielpfad ; done

Kurzes Beispiel:

for i in `locate jpg | grep Photoprojekt | grep August07`; do cp `echo $i` /home/sinux/tmp; done

Sehr praktisch und wandelbar.

Viel Spass damit! 

Ich glaube Wake on Lan (WoL) ist für mich ein Musterbeispiel für eine Technologie, die ich ewig kenne, aber noch nie benützt habe.

Durch den ATX Standard, erhält das Mainboard immer eine Mindestmenge an Strom bereitgestellt, damit es durch einen Impuls selbstständig anlaufen kann. Dieser Impuls kann durch einen Taster (Ein und „Aus“schalter), Bios (Zeitgesteuert), oder eben über Wake on Lan erfolgen.

Dies muss einerseits  durch das Bios des Boards, sowohl von der Netzwerkkarte unterstützt werden. Wobei das zu Zeiten von 8 Kanal HD Audio, Gigabit Onboard, usw. wirklich schon lange Standard ist. Sobald der Rechner nach dem Ausschalten noch an der Netzwerkkarte einen Linkstatus bestätigt, hört die Karte auf das WoL-Signal.

Um den Rechner aufzuwecken, erfolgt ein Broadcast an alle Mac-Adressen (FF:FF:FF ….) mit einem speziellem Magic Paket. Sobald der Karte das Paket erhält, wird der Impuls ans Mainboard geleitet und der Rechner bootet / wacht aus dem Standby aus. Programme zum verschicken eines Magic Packets gibts genug und funktioniert wunderbar, jedoch im LAN. Wir möchten dies Remote übers Internet machen. (Über VPN ergeben sich die Probleme allerdings nicht, da wir dort eine LAN Umgebung haben)

Was aber, wenn ich das übers Internet machen möchte? Ein Mac-Broadcast wird übers Internet bisschen schwierig Antwort: Unicast übers Internet.

Vorbereitung:

Dyndns (oder etwas Äquivalentes) am Router einrichten.

Port Forwarding (Besser nicht den Standardport dafür verwenden, sonst könnte dies Misbraucht werden) auf den Zielrechner.

WoL am Zielrechner aktivieren.

Aufwachen übers Internet: Eine Webseite aufsuchen, die Remote übers Internet den Unicast komfortabel an den Zielrechner (Strenggenommen an den Zielrouter) schickt.

Beispielsweise: http://stephan.mestrona.net/wol/

(Vielen Dank an dieser Stelle für dieses geniale Projekt)

Dieses Verfahrenn, Magic Pakets durch Port-Forwarding durchzustellen, funktioniert bei jedem Router. Auch wenn dieser explizit kein WoL bzw. Broadcasts im Lan durchführen kann.

Viel Spass beim Ausprobieren!

]]> http://defaultuser.wordpress.com/2008/06/20/configure-wake-on-lan-via-internet/feed/ 0 defaultuser http://defaultuser.wordpress.com/2008/05/30/geringer-schreibdurchsatz-nas-mit-linux/ http://defaultuser.wordpress.com/2008/05/30/geringer-schreibdurchsatz-nas-mit-linux/#comments Fri, 30 May 2008 15:03:07 +0000 defaultuser http://defaultuser.wordpress.com/?p=4 ]]>

Vielleicht war es auch fahrlässig zu denken, dass man mit 1Gbit mehr Durchsatz bekommt als mit 100 Mbit FastEthernet. Eine klassische Situation:

2*100 Mbit (trunked) via NFSv3 … gemessener Durchsatz:

Ein guter Wert, nahe der Bruttogrenze von FastEthernet.

1*Gbit via NFSv3 … gemessener Durchsatz:

Auf den ersten Blick schön, jedoch fängt man dann doch zu rechnen an:

Klar, dies ist ein reiner Bruttowert. In der Praxis unerreichbar. Abzüglich Physik, Collisions, IP, Protokolloverhead, Delay, Broadcasts usw. ist wahrscheinlich in einem gemischten Netzwerk mit eher 60 – 70 MB/s zu rechnen. Ich schaffe aber beim Schreibzugriff nur 33 MB.

Woran liegt das?

Nach vielen Versuchen mit alternativen Netzwerkkartentreibern, Switchwechsel, NAS-Update ohne spürbar höherem Durchsatz, gings auf Dateisystemebene…

Die NAS schreibt auf ihrem Filesystem mit 4K Blöcken, mein ext3 ebenfalls. Passt eigentlich hervorragend, ausser: Partial Writes

ClientFS: | 4K Block | 4K Block | 4K Block | 4k Block

BLANdKLAABServerFS: BLAN | 4K Block | 4K Block | 4K Block | 4k Block

Zu sehen sind die verschobenen Blöcke. Wird vom Client content von der NAS geholt, benötigt man zwei 4K Blöcke, um einen 4K Block auszulesen. => Bandbreite halbiert sich.

Ideal wäre:

ClientFS:  | 4K Block | 4K Block | 4K Block | 4k Block

ServerFS: | 4K Block | 4K Block | 4K Block | 4k Block

Einfluss auf die Synchronität der Blöcke zwischen den Filesystemen ist tatsächlich auf Blockebene zu suchen. Durch das Partitionieren + MBR + Bootloader usw. beginnen die Filesysteme in unterschiedlichen Bereichen. Einzusehen ist dies am Partition Offset.

Die Spalte „Start“ definiert die Blockanzahl.

Teilen wir diese durch die Blockgröße, sehen wir das diese nicht perfekt durch 4K teilbar ist.

Bei potenten NAS-System werden wir diese Differenz nicht spüren, da die Anbindung und das Cacheverhalten genau diese Asynchronitäten abdeckt. Bei Consumergeräten mit knapp kalkulierten CPUs bzw. Storagecontrollern merken wir dies leider direkt am am Durchsatz, sodass wir von Hand mögliche Partial Writes verhindern.

Benchmark mit angepasstem Offset:

Fast der doppelte Durchsatz… dabei deutlich weniger CPU Belastung auf der NAS.

Viel Spass beim Tunen

Irgendwie sollte ich die Dinge dokumentieren, mit denen ich mich beschäftige. Sonst erwischt man sich dabei, wie man über die gleichen Stellen häufiger als nötig stolpert.

Und in dieser Form profitiert vielleicht noch jemand anders davon…

Viel Spass!