Netzwerk-Dateisysteme im Vergleich

Die Autoren von remotefs erheben den Anspruch, ein schnelles Netzwerk-Dateisystem geschaffen zu haben. Diese Behauptung soll hier belegt werden.

Von Jean-Jacques Sarton

Einleitung

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 Geschwindigkeit auch ein Aspekt, der 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 einfache Tests wie das Auflisten des Inhaltes eines Verzeichnisses oder das Lesen der EXIF-Daten aller Bilder, die im Verzeichnis gespeichert sind, erfolgen. Hier kann eher die gefühlte Geschwindigkeit des Netzwerk-Dateisystems 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«, d.h. 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 Hardware-Einbindung. Für spezielle Fälle werden Client-seitig 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 beim Darstellen der Dateien in einem 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.

	Sek.	Transaktionen/s				KB/s
	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 von Dateien, die von 500 auf 5000 erhöht wurde, verwendet.

The base number of files is 500
Transactions: 5000
Files range between 500 bytes and 9.77 kilobytes in size
Block sizes are: read=512 bytes, write=512 bytes
Biases are: read/append=5, create/delete=5
Using Unix buffered file I/O
Random number generator seed is 42

Da NFS intensives Caching auf der Client-Seite verwendet, wurden zwei 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 der Anzahl der Dateien die Dateigröße um den Faktor 100 erhöht.

	Sek.	Transaktionen/s				MB/s
	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 von Dateien, die angelegt oder entfernt werden. Die Ergebnisse wurden auf zwei 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		Random Seeks
	Size:Chunk Size	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.

Auch hier ist remotefs zweimal zu finden. Wie beim Postmark Test wurden FUSE-Optimierungs-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.