Ein der Hauptentwicklungsziele von Remotefs ist es einen Server zur Verfügung zu stellen, der auf schwacher Hardware wie z.B. Heim-Routern, trotz geringe Ressourcen, optimal läuft. Das Reservieren von großen Mengen an Speicher und ähnliches ist auf solchen Server nicht von Vorteil, Swapping könnte entstehen. Das Binary sollte klein bleiben. Sowohl unter der X86 wie der ARM Architektur beträgt die Größe der Serverkomponente ca. 60 KBytes.

Klientseitig ist der Lage entspannter. Hier könnten es ruhig einige Bytes mehr sein.

Remotefs versucht jede einzelnen Arbeitsschritt, welcher bei einen Netzwerkzugriff entsteht und auch die Anbindung der Hardware zu optimieren, des heißt geringst mögliche Bearbeitungszeit zu erreichen.

Die Performance wird unter anderem dadurch erreicht, dass FUSE nicht im multithreaded Modus betrieben wird. Nach unseren Untersuchungen erreichen wir dadurch ein gutes Verhalten, da FUSE gezwungen wird Puffer bereit zu stellen und Daten erst zu sammeln und, wenn ausreichend viele vorhanden, sind diese weiter zu reichen.

Die Aufrufe aus der FUSE Bibliothek werden strikt sequentiell bearbeitet. Dies bedeutet, dass die Latenz Zeit erhöht wird (Aufrufe werden nicht überlappend ausgegeben). Dies stellt aber keinen gravierenden Nachteil dar, wenn man vom Anlegen und Löschen von Dateien absieht.
Eine parallele Bearbeitung der Aufrufe würde den Code, sowohl auf der Client wie auf der Server-Seite, verkomplizieren und der Gewinn dürfte trotz allem nicht bedeutend sein.

Da FUSE sich um das "Cachen" der Daten vorbildlich kümmert, sind die in den ersten Versionen vorhandene Cache im Client nicht mehr vorhanden. Dies wirkt sich sogar positiv aus, vor allen im Bezug auf Multithreading. Einziger übrig bleibender Cache und die damit verbundene Sonderverarbeitung, verbleibt beim Öffnen eines Verzeichnisses. Die "Status" Daten der unten gelegenen Objekte werden gesammelt und mit der Bestätigung des Aufrufs übertragen. Dies bedeutet eine längere Verarbeitungszeit. Dieser Nachteil wird aber mehr als kompensiert wenn die Applikation Informationen über die beibehaltenen Objekte anfordert. Langwierige Netzwerkzugriffe entfallen und die gesamte Dauer von Kommando wie "ls -l" oder der Aufbau des Dateimanager Fensters werden drastisch reduziert.

Verschiedene Optionen können auf FUSE beim Aufruf des Clients übergeben werden. Damit kann eine höhere Geschwindigkeit vorgetäuscht werden.

Remotefs ist ein schnelles Dateisystem. Es soll ermöglichen, auf leistungsschwachen Geräten, die für den Einsatz im Heimbereich konzipiert wurden, wie z.B. Network Attached Storage (NAS), einer optimale Anbindung zu gestatten.

Remotefs läuft auf verschiedenen POSIX Systemen wie Linux, OpenSolaris, FreeBSD und Mac OS X.

Remotefs eignet sich auch um über das Internet auf einen Server zurzugreifen. Allerdings muss dies über einen SSL oder SSH Tunnel geschehen.

Remotefs unterstützt IPv6 Verbindungen.

Remotefs unterstützt POSIX ACL.

Voraussetzung für den Betrieb von remotefs

Kompilieren und installieren von remotefs

Die am weitesten fortgeschrittene Version wird bei sourcefoge.net gehostet. Die Sourcen sollten mit svn installiert werden: 

$ svn co https://remotefs.svn.sourceforge.net/svnroot/remotefs

Nach dem Herunterladen in das Verzeichnis remotefs/trunk/build/Makefiles wechseln und die Datei options.mk gegebenfalls anpassen (ACL, ...) aktivieren.
Eine Kopie dieser Datei kann auch unter remotefs/trunk angelegt werden. Der Name dieser Datei muss custom.mk lauten. In diese Dateien werden die mögliche Kompilieroptionen freigeschaltet oder entwertet. Dnach zu zemotefs/trunk wechseln.

Nach diesem Schritt 

$ make client nss; sudo make install
aufrufen. Auf dem Server 
$ make server; sudo make install

Einrichten von remotefs auf dem Server

Remotefs benötigt die Dateien /etc/rfs-passwd und /etc/rfs-exports.

Die Datei rfs-passwd beinhaltet die md5 kodierten Passwörter für den berechtigten Anwender. Sie wird mit dem Dienstprogramm rfspasswd verwaltet.

Die Datei /etc/rfs-exports beinhaltet die Verzeichnisse die zu exportieren sind sowie die zugelassenen Anwender/IP-Adressen und den Exportmodus. 

# Export für Anwender alice wenn der Zugriff vom Rechner
# mit IP-Adresse 10.1.1.1 erfolgt
# UNIX Rechte werden benutzt, ACL wenn vorhanden sind effektiv
/home/alice       alice@10.1.1.1     (ugo)
# Export für Anwender alice wenn der Zugriff vom Rechner
# mit IP-Bereich 10.1.1.0/24 erfolgt
/home/alice       alice@10.1.1.0/24  (ugo)
# Export für Anwender anna unabhängig von der IP des Rechners.
# Auf den Server wird als
# Anwender alice:alice verwendet.
/home/alice       anna              (user=alice,group=alice)
# Export für Anwender bob, UNIX Rechte werden nicht ausgewertet
/home/bob         bob                ()
# Export für jedermann wenn die IP Adresse stimmt, Mode
# nur lesend
/shared/filme     10.1.1.1, 10.1.1.2 (ro)
# Alice und Bob können auf dies exportierte Dokumenten
# zurückgreifen,
# ACL sollte in diesem Fall Verwendung finden
/shared/dokumente alice, bob         (ugo)
# Verzeichnis ist von allen Anwender (nur lesend) erreichbar.
/shared/musik    * (ro)

Einrichten von remotefs auf dem Client

Die einzige Datei die vorhanden sein muss ist eine Datei die das Passwort des Anwenders beinhaltet. Diese Datei sollte passend geschützt sein (kein Leserechte für die Gruppe und den Rest der Welt). Damit wird vermieden dass das Passwort als Argument rfs übergeben wird und damit in Klartext erscheint.

Die Logindaten werden verschlüsselt über das Netzwerk ausgetauscht so dass das Passwort nicht, oder nur mit hohen Aufwand, entschlüsselt werden kann.

Starten des Client rfs

rfs -ousername=anton,passwd=passwortDatei server:/share ~/priv_mnt

Die Logindaten werden verschlüsselt über das Netzwerk ausgetauscht so dass das Passwort nicht ohne großen Aufwand entschlüsselt werden kann.

Erweitertes ID-Mapping

Die Namensauflösung unter UNIX® wird unter Verwendung von NSS Name Service Switch vorgenommen. In der Datei /etc/nsswitch.conf werden Module für die verschiedene Zwecke aufgelistet. rfs_nss stellt solch ein Modul zur Verfügung.

Dieses Modul (rfs) muss in der Datei /etc/nsswitch.conf eingetragen werden. 

passwd: files rfs
group:  files rfs

Der Eintrag rfs sollte der letzte Eintrag in einer Zeile sein, 

$ ls -l mnt/home
drwxr------ 1 anton     anton     4096  24. Jan 13:53 anton
drwxr------ 1 bernd@nas bernd@nas 4096  27. Jan 19:42 bernd

@[IP-Adresse|RechnerName] wird automatisch den Anwender- Gruppen-Name angehängt, damit ist eine eindeutige Kennzeichnung der Zugehörigkeit sichergestellt.

Wenn das NSS Dienst nicht aktiviert wurde oder aus irgendwelche Gründe nicht vorhanden ist, erfolgt eine Umsetzung der "fremden Namen" nach nobody, nogroup oder, falls den Anwender nobody nicht vorhanden ist, nach root. 

$ ls -l mnt/home
drwxr------ 1 anton   anton   4096  24. Jan 13:53 anton
drwxr------ 1 nobody  nogroup 4096  27. Jan 19:42 bernd

Wenn die ACL Unterstützung konfiguriert wurde, ist den Zugriff auf gemeinsame Dateien leicht möglich und die Zugriffsrechte können gezielt vergeben werden.

Damit können zum Beispiel im Ordner GemeinsameDaten Dateien vorhanden sein auf den Anton sowie Bernd Schreib- und Leserechte besitzen, Christian keinerlei Rechte besitzt und Dieter nur Leserecht hat. 

$ getfacl -t mnt/GemeinsameDaten/datei
# file: datei
# owner: anton
# group: anton
user::rw-
user:anton:rwx
user:bernd@nas: rwx
user:christian@nas: ---            
user:dieter@nas: r-x
group::---
mask::rw-
other::---

Im Gegensatz zu Netzwerk Dateisystemen wie NFS, GlusterFS und so weiter, ist remotefs nicht für den gleichzeitigen Zugriff von etlichen Anwender konzipiert.
Der Zugriff erfolgt streng sequentiell (je Anwender) und neue Kommandos werden nicht überlappend, wie z.B. mit NFS bearbeitet. Dies stellt aber im Anwendungsbereich, bei den es nur eine sehr begrenzte Anzahl an Anwendern gibt, kein Nachteil. Für ein Firmennetz ist remotefs sicherlich nicht die erste Wahl. NFS würde hier von der leistungsfähigeren Hardware und den eingebauten Mechanismen profitieren.

Auch wenn remotefs nicht für den Einsatz in multithreaded Applikationen konzipiert wurde, bedeutet es nicht, dass dadurch gravierende Nachteile einstehen. Bei Applikationen die Konkurrierende Zugriffe verursachen, werden diese nacheinander bearbeitet und die gesamte Verarbeitungszeit ändert sich nicht stark. Ein einfacher Test, z.B. Anlegen von 1000 Dateien mit anschließendem übertragen von Daten ergibt eine Verschlechterung der gesamt Übertragungszeit um ca. 10 %. FUSE sammelt die Daten und wenn diese 128 KByte erreicht haben oder ein "Close" Aufruf erfolgt, werden diese über das Netzwerk geschickt. Damit profitiert remotefs von der ausgezeichneten FUSE Library und dem Kernel Modul.

Einbinden/Aushängen per Maus-Klick

Neben den oben aufgeführten Befehle ist es auch möglich das Einbinden/Abhängen des entferntes Verzeichnis im Desktop (Gnome) einzurichten. Für andere Desktop kann Gigolo verwendet werden.

Damit dies funktionniert ist ein Eintrag in der Datei /etc/fstab nowendig. Ferner müssen die Scripte /sbin/mount.rfs und umount.fuse.rfs vorhanden sein.

Das mount.rfs Script überprüft ob die Optionen aus der Datei /etc/fstab für rfs bestimmt sind oder verworfen werden müssen.
Damit sichergestellt wird, dass das Einbinden nur von Berechtigten erfolgen wird, wird einer Option uid=UID oder gid=GID erwartet. das Script überprüft ob diese Optionen angegeben wurden und verweigert das Einbinden wenn in der Datei /etc/fstab kein passenden Eintrag vorgefunden wurde.

Die Datei /etc/fstab könnte solch ein Eintrag beinhalten 

# fstab Beispiel
nas:/home/anton/nas /export/anton rfs username=anton,password=/home/anton/.rfs/nas.passwd,uid=anton,defaults,users,noauto 0 0

Für andere Desktop Umgebungen kann gigolo (ist Bestandteil von Xfce) verwendet werden.

Einbinden via /etc/fstab auf eine andere Art

Mit nachstenden Eintrag in der Datei /etc/fstab wird die Verzeichnis /exports/bob des Servers mit name nas auf das Verzeichnis /mnt/nas eingehängt. Alle Anwender können die Dateien unter /mnt/nas anschauen und, falls diese Verzeichnis nicht im Modus ro (nur lesend) exportiert wurde, Veränderungen vornehmen 

nas:/exports/bob /mnt/nas uid=bob,gid=bob,mountbyroot,allow_other 0 0

nas:/exports/alice steht für alle Anwender zur Verfügung, eine Veränderung der Daten ist nicht möglich wenn auf den Server das Export als ro (nur lesen) deklariert wurde. 

nas:/exports/alice /mnt/alice uid=root,allow_other,ro,_netdev 0 0

Besondere Szenarien

Ein Ordner kann so exportiert werden, dass ein bestimmten Anwender volle Zugriffsrechte besitzt und alle andere nur Leserechte erhalten. Dafür müssen allerdings 2 getrennte Anweisungen in der Datei /etc/rfs-exports vorhanden sein. 

/exports/shared * (ro)
/exports/shared_b bob ()

/exports/shared_b ist lediglich ein Link auf /exports/shared. Links die auf Verzeichnis zeichen werden als Folder behandelt.

Wenn ein Verzeichniss von verschiedene Anwendern geteilt werden soll und die Zugriffsrechte innerhalb des Exports unterschiedlich sein sollen sind rfs und rfsd mit ACL Support zu kompilieren. Ein export könnte so aussehen 

/exports/alice_bob alice,bob (ugo)

Sowohl Alice und Bob dürfen /exports/alice_bob einbinden wobei das Einhängepunkt als privat auszulegen ist. Mittels POSIX-ACL kann sichergestellt werden, dass manche Dateien oder Ordner nur von Alice verändert werden können. Andere Objekte können enzweder nur Bob oder sowohl Alice wie Bob "gehöhren"

Sichere Einbindung über das Internet

Den Datenaustausch zwischen Client und Server erfolgt unverschlüsselt. Dies für ein Zugriff über das Internet nicht immer Sinnvoll.

Über ein ssh Tunnel läst sich dennoch eine gesicherte Verbindung erstellen. Dafür sind nur 2 Kommandos abzusetzen: 

ssh -T -L 5001:localhost:5001 <remote_host> -f sleep 10
rfs localhost:<Folder> /home/anton/<Einhängepunkt<>

Mittel ein kleinen Script kann dies komfortabel erledigt werden: 

#!/bin/sh
################################################################
# File: srfs.sh (secure rfs mount)
#
# This is a sample how to create shell script allowing to mount
# or umount a remotefs files system via a ssh connection.
#
################################################################

# SSH parameters:
# ---------------

#   You may comment this in in order to choose you prefered
#   GUI for password entry, default is the box provided by openSSH
#SSH_ASKPASS=/usr/bin/gaskpass
#export SSH_ASKPASS

SSH_USER=guest
R_HOST=192.168.1.4                  # Name or IP for the files system server

# RFS parameters:
# ---------------
MOUNTPOINT=$HOME/Network/secure_rfs # Where to mount the file system
R_DIR=/home                         # directory exported by remotefs

RFS_USER=$SSH_USER                  # login name for the remotefs server
                                    # we assume that the name is the same for
                                    # ssh and remotefs

RFS_PWD=$HOME/192.168.1.4.passwd    # file with password see rfs(1)
                                    # if RFS_PWD is empty, we will not
                                    # pass the option username,... to rfs

# askYN()
# If we are launched on a terminal we have to return yes or no on
# some question, do this until we have a valid answer

askYN()
{
    while :
    do
        echo -en "$1 (yes/no) ? : "
        read ans;
        case $ans in
        y*|Y*)
            return 0;;
        n*|N*)
            return 1;;
        esac
    done
}

# askYesOrNo()
# Ask for yes or no according to the environment
# (launched from a terminal or as GUI)
askYesOrNo()
{
    QUESTION=$1
    if tty | grep /dev/ #> /dev/null
    then
        askYN "$R_HOST:$R_DIR unmount"
    else
        zenity --title=rfs --question --text="$QUESTION $R_HOST:$R_DIR ?"
    fi
    return $?
}

# mountfs()
# mount the remotefs file system via a ssh tunnel
mountfs()
{
    if [ ! -z "$RFS_PWD" ]
    then
        RFS_OPTS="-o username=$RFS_USER,password=$RFS_PWD"
    fi
    ssh -T -L 5001:localhost:5001 $SSH_USER@$R_HOST -f sleep 10
    rfs $RFS_OPTS localhost:$R_DIR $MOUNTPOINT
}

# umountfs()
# unmount the remotefs file system
umountfs()
{
    fusermount -u $MOUNTPOINT
}

####
# MAIN part, check first if mounted and call the correct command
####
if grep "$MOUNTPOINT" /etc/mtab #> /dev/null
then
    if askYesOrNo unmount
    then
        umountfs
    fi
else
    if askYesOrNo mount
    then
        mountfs
    fi
fi

Wenn das Script aus ein Terminal aufgerufen wird, erfolgt (wenn nötig) die Passwortanforderung über das terminal.
Wird das Script auf den Desktop oder die taskbar abgelegt (Starter) erfolgt die Passwortabfrage mittels das in der Variable SSH_ASKPASS angegebene Program ansonsten über der von openSSH mitgelieferte Eingabebox. Die Fragen bezüglich Einbinden oder Aushängen werden entweder über das Terminal oder zenity gestellt.

Netzwerk Systeme im Vergleich

Die Autoren von remotefs erheben den Anspruch ein schnelles Netzwerk Datei System geschaffen zu haben. Solch eine Behauptung muss natürlich belegt werden.

Um Dateisysteme zu vergleichen sind verschiedene Aspekte zu berücksichtigen.
Neben der reinen Funktionalität (POSIX-Rechte, ACL, Unterstützung für Links usw.) ist die Schnelligkeit (Performance) auch ein Aspekt welcher betrachtet werden muss.

Die erste Frage ist, wie die Performance objektiv beurteilt werden kann. Es existieren Suiten, die die Durchführung von synthetischen Tests erlauben. Ob diese Tests auch immer geeignete Ergebnisse Liefern ist fraglich, zumal vorwiegend die Übertragungsrate für Dateien ermittelt wird. Das Auflisten aller Dateien, inklusive deren Eingenschaften (Eigentümer, Größe,...), die sich in einem Verzeichnis befinden, wird nie durchgeführt. Laut manchen Autoren sind alle bekannten Testsuiten für Netzwerkdateisysteme mehr oder weniger fehlerhaft. Zudem können durch geeigneten Wahl der Parameter die Ergebnisse zur Gunsten des einen oder anderen Systems beeinflusst werden.

Neben solchen Tests sollten auch einfachen Tests wie das Auflisten des Inhaltes eines Verzeichnises oder das Lesen der Exifdaten aller Bilder die im Verzeichnis gespeichert sind auch erfolgen. Hier kann eher die gefühlte Geschwindigkeit des Netzwerk Datei System ermittelt werden.

Um gute Performance, auf leistungsschwacher Hardware zu erreichen, des heißt auf Hardware die eine geringe CPU Leistung und wenig RAM aufweist, kann das Mittel "Caching", des heißt Daten für den hypothetischen Fall dass sie gebraucht werden im Speicher halten, nicht die Lösung sein.

Der Hauptansatz von remotefs ist eine optimierte Netzwerk- und Hardwareeinbindung. Für spezielle Fälle werden Klientseitig manche Daten gehalten, dies aber nur für sehr kurze Zeit. Wenn z.B. der Inhalt eines Verzeichnisses ausgelesen wird, wie beim Absetzen des Kommandos "ls -l", oder das Darstellen der Dateien in einen Dateimanager, werden Daten auf Verdacht gesammelt und übertragen. Damit können Wartezeiten drastisch verkürzt werden.

Postmark

Postmark ist ein synthetischer Test welcher versucht, entsprechend der zu erwartenden Belastung bei einem News oder Mail Server, die Performance zu messen.

Sec. Transaktionen/s kilobytes per second
Dauer Create read append delete read write
glusterfs 49 125 50 51 280 290.30 357.19
cifs 47 125 48 69 264 307.05 377.80
remotefs 26 250 97 104 560 550.57 677.43
remotefs 2 25 250 98 101 560 570.34 701.63
nfs 19 500 129 133 560 760.31 935.50

Die Defaultwerte für den Test wurden, bis auf den Anzahl an Dateien, welches von 500 auf 5000 erhöht wurde, verwendet.

Da nfs intensives Caching auf der Klientseite verwendet, wurden 2 Tests mit remotefs durchgeführt. Bei der Zeile remotefs 2 wurde kernel caching eingeschaltet.

Cifs und glusterfs weisen die schechtesten Werte auf. Remotefs gewinnt geringfügig an Performance durch Einschalten des kernel_caching und ist nicht so gut wie nfs.

Da die Dateigröße auch eine Rolle spielt wurde, anstelle des Anzahl an Dateien, die Dateigrößen um den Faktor ein hundert erhöht.

Sec. Transaktionen/s Megabytes per second
Dauer Create read append delete read write
nfs 163 2 1 1 164 4.03 12.02
remotefs 177 3 1 1 246 4.31 12.84
remotefs 2 161 3 1 1 492 4.55 13.56

Remotefs schneidet hier besser als nfs ab.

Bonnie++

Bonnie++ misst einerseits die Transferrate anderseits den Anzahl an Dateien die angelegt oder entfernt werden. Die Ergebnisse wurden auf 2 Tabellen verteilt.
Da der Server 128 MB RAM besitzt wurde, um Caching Effekte auf der Server Seite zu eliminieren, bonnie++ mit den Parametern -r128 -s256 aufgerufen.

Sequential Output Sequential Input Random Seeks
Size:Chunk Size Per Char Block Rewrite Per Char Block
K/sec % CPU K/sec % CPU /sec % CPU K/sec % CPU K/sec % CPU / sec % CPU
cifs 256M 7300 33 8567 7 8080 4 10798 31 +++++ +++ 210.1 1
nfs 256M 12187 30 13312 2 15109 3 59638 98 +++++ +++ 3035.4 2
glusterfs 256M 12303 31 13851 2 15198 3 60737 99 +++++ +++ 2856.9 3
remotefs 256M 17685 43 18487 4 9348 3 20582 54 20061 2 571 1
remotefs 2 256M 18241 45 18650 4 19583 5 59261 99 +++++ +++ 8437.5 4

Die Transferrate die angezeigt wird ist zum Teil zweifelhaft, alles oder fast alles erfolgt auf den Client. Manche Werte sind sehr hoch, bezeichnend ist auch, dass die CPU Leistung des Clients fast zu 100% ausgenutzt wird.

Hier ist auch remotefs 2 mal zu finden, wie beim Postmark Test, wurden FUSE Optimierung Optionen eingeschaltet. Daraus ist ersichtlich dass internes Caching eine große Rolle spielt. Hier ist auch remotefs 2 mal zu finden, wie beim Postmark Test, wurden FUSE Optimierung Optionen eingeschaltet. Daraus ist ersichtlich, dass internes Caching eine große Rolle spielt.

Erstaunlicherweise sind bei diesem Test nfs und glusterfs gleich gut. Dies entspricht nicht den Ergebnissen des vorgehenden Tests. Die Rahmenbedingungen sind auch ganz anders.

Remotefs ist scheinbar (remotefs 2) besser als nfs welches bei den Tests zuvor Klassenprimus war.

Num File Sequential Create Random Create
Create Read Delete Create Read Delete
/ sec % CPU / sec % CPU / sec % CPU / sec % CPU / sec % CPU / sec % CPU
cifs 16 165 2 918 3 330 2 163 2 1204 3 344 2
nfs 16 411 4 2690 12 488 5 415 4 3177 13 479 4
glusterfs 16 399 4 2740 12 477 4 404 5 3172 13 469 4
remotefs 16 363 2 2806 2 599 1 369 2 2275 2 571 1
remotefs 2 16 377 2 2911 2 621 1 368 1 2026 2 553 1

Die Ergebnisse dieser Tabelle entsprechen wie zuvor nicht den Erkenntnissen des Postmark Tests. Nfs und glusterfs weisen recht ähnliche Werte auf, cifs ist weit abgeschlagen.

Eigene Testprogramme

Tests sind wie Statistiken und sind nur dann glaubhaft wenn diese die gewünschten Ergebnisse nach den Motto "glaube nur was du selbst verfälscht hast", zeigen.

Das eingesetzte Tool ist entgegen den Testprogrammen Postmark oder Bonnie++ nicht zur Ausarbeitung von Benchmark Werten ausgelegt, aber vielmehr zur gezielten Untersuchung und Entdeckung von Schwachstellen entwickelt worden. Da manche Testsuiten wie z.B. iozone sehr lange Laufzeit haben (mehrere Stunden), musste ein praktikabler Weg erarbeitet werden, Tests gezielt durchzuführen, ohne dass alle wichtige Aspekten immer wieder beim Einsatz des Tools geprüft werden.

Dadurch, dass einzelne Tests durchgeführt werden können, wie z.B, das Kopieren einer oder mehrerer Dateien mit einer vorgegebenen Größe oder das Anlegen eines Verzeichnisses mit anschließender Erzeugung von Dateien, können Erkenntnisse schnell gewonnen werden und der Netzwerkverkehr und das Timing leichter untersucht werden.

Da die remotefs Test nicht für Benchmarking ausgelegt wurden aber zur gezielte Untersuchung einzelner Vorgänge ausgelegt wurden, sind manche Diskrepanzen zu etablierten Benchmarktests vorhanden. Die erzielten Ergebnisse können aber weitgehend im Einklang mit den Resultate der Benchmark Programme gebracht werden.

Schreib Test

Schreibgeschwindigkeit

Bei diesem Test wurden Dateien in der Größe 1 kByte bis 256 MByte auf dem Client erzeugt, die entsprechenden Zieldateien auf den Server erzeugt und danach die Zeit gemessen die zur Übertragung des Inhaltes benötigt wurde. Die für das Anlegen der Datei benötigte Zeit hat somit kein Einfluss auf die Resultate.

Für den Test im linken Bild wurde jeweils nur 1 Datei erzeugt, beim rechten Bild sind die Ergenisse der Tests für jeweils 1024 Dateien oder 256 MBytes an Daten aufgeführt.

Bei dem Test mit jeweils einer Datei verschiedener Größe werden höhere Datenraten (MBytes/s) erreicht als bei den Test mit bis zu 1024 Dateien. Dies dürfte eine Folge des serverseitigen Cachings (Kernel, Festplatte) und des verzögertes Schreibens sein.

Remotefs weist hier sehr gute Werte auf, glusterfs und cifs sind hier ebenbürtig. Nfs ist bei größeren Datenmenge nicht so leistungsfähig wie die anderen Dateisysteme. Bei kleineren Dateien (bis 64 kByte) werden aber bessere Werte als mit glusterfs oder cifs erreicht.

Lese Test

Lesegeschwindigkeit

Die mit den vorhergehenden Tests auf den Server kopierten Dateien wurden auf den Client zurück kopiert. Wie zuvor sind Unterschiede zwischen der Übertragung der Daten einzelner und mehrerer Dateien erkennbar.

Um Effekte die mit Caching zu tun haben zu vermeiden. wurden nach dem write Test die Dateisysteme ausgehängt und wieder eingebunden. Dennoch scheint, vor allem bei nfs, das Vorhaben nicht ganz geglückt zu sein.

Hier ist, wie beim Schreibtest, ersichtlich dass die Belastung des Systems eine Rolle auf die erzielbare Performance spielt. Die Verschiedene Komponenten eines Systems weisen Puffern aus (z.B. Festplatte) die bei größere Altivitäten den Aufkommen an Datenverkehr nicht mehr bewältigen können. Damit ergeben sich zwangsläufig niedriegere Übertragungsgeschwindigkeiten.

Create/Delete Test

Create/sDelete/s
cifs165267
glusterfs194255
remotefs368563
nfs580590

Bei dieser Test wurden 1000 leere Dateien in einem leeren Verzeichnis angelegt und anschließend gelöscht.

Nfs scheint hier sehr gut optimiert zu sein, und dies mach sich auch auf die Ergebnisse von Postmark bemerkbar. Die Ergebnisse stehen aber nicht ganz im Einklang mit diesem Benchmark. da lediglich leere Dateien erzeugt wurden. Dadurch entfällt auf dem Server einiges an Festplattenzugriffen und die Werte des Tests sind dementsprechend hoch.

Einfache Praxis bezogene Tests

Praxisgerechte Testwerte sind genauso wie die bei Benchmark Programmen zur Verfügung gestellte Daten mit Vorsicht zu betrachten. Was bei einem Anwender Praxis ist, muss bei einen anderen Anwender nicht unbedingt übereinstimmen.

Einige Operationen die von gebräuchlichen Benchmark Tests nicht abgedeckt werden können mittels recht einfachen Tests auf Shellebene durchgeführt werden.Beim navigieren durch die eigene Datensammlung mittels einem Dateimanager wird immer wieder der Inhalt der Verzeichnis wie auch die Attribute der enthaltene Objekte ermittelt. Bei einer großen Anzahl an Dateien sind damit Wartezeiten "programmiert".

Zeit für die Ausführung des Kommando "ls -l Verzeichnis" wobei sich 10000 Dateien im Verzeichnis befinden

glusterfs13.494 sec.
cifs10.212 sec.
nfs3.943 sec.
remotefs3.767 sec.

Ergebnis von "time exiv2 * >/dev/null" für 431 Bilder

glusterfs0m24.683s
cifs0m6.388s
remotefs0m3.572s
nfs0m2.386s

Kopieren eines Ordners mit verschiedenen Bildern

Als Befehl wurde time cp -rp QuelleVezeichnis ZielVerzeichnis Bzw. time cp -r QuelleVezeichnis ZielVerzeichnis verwendet.

Insgesamt waren 38 MBytes an Daten zu kopieren, 2 Unterverzeichnis waren vorhanden. Die kleinste Datei hatte eine Größe von 1483 Bytes die größte wies 5482568 Bytes auf.
Insgesamt waren 34 Dateien zu kopieren und 3 Verzeichnis zu erzeugen.
Da die Ziele vorhanden waren, mussten die Dateien und Verzeichniseinträge erstmal überschrieben werden und die Rechte und Zeitstempel richtig gestellt werden.
Der Test wurde mit einem frisch eingebundenen Dateisystem vorgenommen. Damit war sichergestellt, dass es nicht zur Verfälschung der Ergebnisse kommt.

Client->ServerServer->Client
cp -rpcp -rcp -rp
cifs-0m2.726s0m2.315s
glusterfs0m3.076s0m2.910s0m2.556s
nfs0m2.633s0m2.614s0m1.673s
remotefs0m2.524s0m2.376s0m1.640s

Nfs und remotefs bringen ähnliche Ergebnisse. Cifs versagte bei einen Test wegen nicht vorhandener Rechte. Dies deutet auf einen Fehler auf der Server Seite, also in der benutzten Version von Samba (3.0.24).

Einfluss der Netzwerk Schnittstelle

Da viele Routern nur eine Netzwerkschnittstelle besitzen die maximal 100MBps erlaubt, wurde mit dem Kommando "ethtool -s eth0 speed 100 autoneg off" eine passendere Testumgebung eingestellt. Die Abhängigkeit im Bezug auf der Netzwerk Daten sollte damit beleuchtet werden. Die Überprüfung sollte auf nfs und remotefs beschränkt bleiben. Es stellte sich aber heraus, dass die im NAS verbauten Netzwerkkomponente nicht für solch ein Test geeignet sind.
Ein alter PC mit 800 MHz Athlon Prozessor wurde zum Leben erweckt und diente als "Server-Ersatz". Die erhobenen stichprobenartigen Daten können daher nicht direkt mit den Ergebnissen der Tests gegen das NAS von Bufallo verglichen werden, zumal die Postmark Defaultwerte verwendet wurden.

Postmark

Die default Werte von Postmark wurdenvwewendet. Trotz geringe Messdauer sind schon Aussage kräftige Daten vorhanden.

Sec. Transaktionen/s Kilobytes per second
Dauer Create read append delete read write
nfs 4 125 60 64 528 155.25 505.87
remotefs 2 250 121 128 528 279.45 910.56
remotefs 2 2 250 121 128 528 349.31 1110.00

Erstaunlicherweise sind die Ergebnisse für nfs nicht so gut wie es zu erwarten wäre. Remotefs schlägt sich im Vergleich zur Test mit dem NAS Gerät besonders gut. Das nfs Protokoll verursacht wahrscheinlich ein größeren Overhead. Dies macht sich bei langsamere Netze bemerkbar.

Praxis Tests

Wie beim Test gegen das NAS wurden mit das kommando cp -rp ein Verzeiznis samt inhalt kopiert.

client->serverserver->client
remotefs0m3.777s0m3.812s
nfs0m4.644s0m4.994s

Remotefs Tests

Um die Transferrate beurteilen zu können wurde eine Datei mit eine Größe von 100 MBytes zum Server und zurück kopiert. Bei diesem Wert sollte die erreichbare Transferrate ermittelbar sein.

WriteRead
remotefs10.328 MBps10.455 MBps
nfs8.817 MBps11.102 MBps

Die maximale Geschwindigkeit beim Übertragen von Daten beträgt nicht 12.5 MByte/s (100Mbps/8) aber ein geringeren Wert. Bei eine IPv4 Verbindung beträgt den Overhead ca 44 Bytes (inklusive Synchronisierung) bei eine Telegrammlänge von 1518 Bytes. Dazu ist noch der Overhead welches von der jeweilige Applikation verursacht wird, abzuziehen. Ohne den vom der Applikation benötigten Overhead ist damit eine Übertragungsrate von lediglich ca. 12 MB/s erreichbar diese verringert sich noch durch Latenzzeiten beim Quittungsverkehr, Wartezeiten auf der Festplatte und so weiter. Die ermittelte Werte zeugen, dass die erreichte Werte nah am Maximum sind.

Fazit

Die von bonnie++ ausgegebenen Werte bei den Tests Sequential Output stimmen einigermaßen mit den selbst ermittelten Werten überein, wobei glusterfs besser abschneidet als es aufgrund der eigene Testprogramm sein dürfte. Dies bedeutet das Glusterfs offenbar einige Optimierungen aufweist, die gute Durchsatz Werte unter bonnie++ erlauben. Ob diese Optimierungen sich wirklich im Heimbereich bemerkbar machen ist fraglich.
Cifs schneidet schlecht ab, dies dürfte aber eine Folge der gewählten Test Parameter sein. Ein Manko von cifs scheint jedoch die zu geringe Performance beim Anlegen oder Löschen von Dateien zu sein.
Nfs kompensiert offenbar die geringere Schreibgeschwindigkeit durch besseres Verhalten beim Anlegen von Objekten oder Lesen der Dateiattributen.
Remotefs erreicht recht gute Werte und könnte weiter verbessert werden, aber auf Kosten eine höhere Komplexität.

Die tendenzielle Performance der getesteten Netzwerkdateisysteme wird durch Postmark bestätigt, wobei glusterfs eine Ausnahme darstellt. Der Anwendungsbereich von glusterfs ist aber nicht das heimischen Netz sondern Rechenzentren mit leistungsfähiger Hardware und verteilter Datenhaltung. Tests in der vorgesehenen Umgebung dürften ganz anders ausfallen als hier.
Nfs glänzte bei den Postmark Tests gegen das NAS System. Dies zeugt von einem sehr guten Verhalten beim Anlegen und Löschen kleine Dateien. Remotefs konnte sich bei den Test mit den Athlon Rechner mit 100 Mbps Ethernet verbindung behaupten, allerdings wurden nur wenige Tests durchgeführt.
Mit einer geeigneter Wahl der Parametern hätte der eine oder andere Kandidat sicherlich bessere Eingenschaften aufgewiesen. Das Postmarktest mit größere Dateien zeugt davon.

Remotefs und nfs sind gemäß den Praxisgerechteren Tests, im Bezug auf Performance gleichwertig. Dies darf aber nicht zu hoch bewertet werden. Solche Ergebnisse sind sehr von der Größe und Anzahl an Objekte abhängig.

Eigenschaften der getesten Dateisysteme

Mit nfs wird nfs Version 3 angenommen. Mit nfs Version 4 sollte die Unterstützung von IPV6 möglich sein und die Internetfähigkeit besser als mit den vorhergehenden Versionen sein. Nfs 4 unterstützt aber nicht das von Linux bekannten ACL Modell, dafür wird ein Modell verwendet welches sich an Windows 2000 anlehnt.

Alle untersuchten Netzwerk Datei Systeme bieten keine Verschlüsselung. Einzig remotefs erlaubt es auf sehr einfache Art über ssh oder stunnel eine gesicherte Verbindung aufzubauen. Nfs Version 4 sollte die Möglichkeit der Verschlüsselung bieten. Dies wurde aber nicht untersucht zumal der Aufwand in diesem Fall relativ hoch ist.

Die getesteten Netzwerk Datei Systeme setzen voraus, dass die Rechnern des Netzes sauber administriert werden.
Nfs v3 bittet die Möglichkeit unbekannte Eigentümer auf nobody zu setzen. Mit Nfs v4 wurde dies verbessert, spezielle Dienste müssen aber laufen.
Cifs erlaubt es auch "Fremden Name aufzulösen", dafür muss aber ein zentrale Server Komponente eingerichtet werden.
Remotefs bittet vom Haus aus die Möglichkeit fremde Namen anzuzeigen wobei diese mit @Rechner-IP oder @Rechner-Name ergänzt werden. Ein speziellen Dienst ist hiefür nicht erforderlich, dafür muss ein Eintrag in der Datei /etc/nsswitch.conf erfolgen.

Sowohl nfs wie glusterfs fordern dass die entfernten Verzeichnisse mit administrative Berechtigung eingebunden werden.
Von cifs freigegebene Verzeichnisse können zwar über den Datei Manager eingebunden werden, wichtige Eingenschaften gehen dadurch verloren. Das Einbinden als "root" stellt die bessere Wahl dar.
Mit remotefs können jederzeit von ein berechtigten Anwendern exportierten Verzeichnisse eingebunden werden.

Im Familien Unternehmen oder in der W.G. darf nicht erwartet werden, dass alle vorhandene Rechner eine Liste alle Anwendern, dies mit eindeutiger nummerische Kennung (UID), besitzen. Kollisionen sind vorprogrammiert. Wenn Anna und Bernd jeweils ein Rechner besitzen und selbst eingerichtet haben, dürften beide die gleiche UID besitzen.
Auf den Server müssen natürlich alle berechtigten Anwender bekannt sein. Es aber möglich ein Verzeichnis, welches nur lesend zur Verfügung gestellt wird, ohne Anwenderangaben einzubinden.

Eingesetzten Hardware

Client:

Server:

Eingesetzten Software

Literatur

Autor

Jean-Jacques Sarton