Sie sind nicht angemeldet.

Anzeigen

**Wir werden in den kommenden Tagen einen Umzug auf einen neuen Server durchführen. Im Rahmen dieser Maßnahme wird das Forum ca. 1 Stunde nicht erreichbar sein.** nslu2-info.de ist ein privates Projekt von mir, welches jeden Monat aus eigener Tasche finanziert wird. Mit einer freiwilligen Spende wird der Erhalt und der weitere Ausbau dieses Forums unterstützt. Um mich beim Erhalt des Forums zu unterstützen, kannst Du entweder via Flattr oder Paypal spenden. Ich bedanke mich schon jetzt bei allen Unterstützern.

Lieber Besucher, herzlich willkommen bei: Die NSLU2 Community****wenns ums speichern und streamen geht****. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

maestrox

Schüler

  • »maestrox« ist der Autor dieses Themas

Beiträge: 54

Firmwareversion / your current Firmware: originale Firmware 2.3r24

  • Nachricht senden

1

Mittwoch, 11. März 2009, 08:31

NFS viel zu langsam

Hi,
ich habe auf meiner slug Debian/NSLU2 (armel) 5.0 Stable Release am laufen. Jetzt wollte ich mal wieder mit meiner dbox per nfs aufnehmen, nur leider bricht die Aufnahme immer ab.
Es kommt die Fehlermeldung, dass die Daten nicht schnell genug geschieben werden können. Mit unslung 6.8 + nfs war das kein Problem.
Habe mal von meiner dbox auf seinen Netzwerk test gemacht um die Geschwindigkeit zu ermitteln. Hoffe ihr könnt mir helfen um die "Bremse" zu lösen.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
var # /tmp/netztest 192.168.2.77 /disk/dbox/aufnahmen /mnt/filme

4096, 4096
8192+0 records in
8192+0 records out
real    2m 30.20s
user    0m 0.34s
sys     0m 13.07s
[COLOR=Red]3390[/COLOR]
8192+0 records in
8192+0 records out
real    1m 45.36s
user    0m 0.21s
sys     0m 10.14s
[COLOR=Red]4876[/COLOR]
192.168.2.77:/disk/dbox/aufnahmen on /mnt/filme type nfs (rw,v3,rsize=4096,wsize=4096,soft,udp,nolock,addr=192.168.2.77)

6144, 6144
8192+0 records in
8192+0 records out
real    2m 29.90s
user    0m 0.23s
sys     0m 13.08s
[COLOR=Red]3413[/COLOR]
8192+0 records in
8192+0 records out
real    1m 47.78s
user    0m 0.19s
sys     0m 10.48s
[COLOR=Red]4785[/COLOR]
192.168.2.77:/disk/dbox/aufnahmen on /mnt/filme type nfs (rw,v3,rsize=4096,wsize=4096,soft,udp,nolock,addr=192.168.2.77)

8192, 8192
8192+0 records in
8192+0 records out
real    2m 16.98s
user    0m 0.30s
sys     0m 12.40s
[COLOR=Red]3710[/COLOR]
8192+0 records in
8192+0 records out
real    1m 38.47s
user    0m 0.11s
sys     0m 7.76s
[COLOR=Red]5224[/COLOR]
192.168.2.77:/disk/dbox/aufnahmen on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.2.77)

9216, 9216
8192+0 records in
8192+0 records out
real    2m 16.35s
user    0m 0.22s
sys     0m 12.19s
[COLOR=Red]3737[/COLOR]
8192+0 records in
8192+0 records out
real    1m 39.43s
user    0m 0.31s
sys     0m 8.31s
[COLOR=Red]5171[/COLOR]
192.168.2.77:/disk/dbox/aufnahmen on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.2.77)

10240, 10240
8192+0 records in
8192+0 records out
real    2m 16.30s
user    0m 0.23s
sys     0m 12.01s
[COLOR=Red]3737[/COLOR]
8192+0 records in
8192+0 records out
real    1m 40.19s
user    0m 0.29s
sys     0m 8.47s
[COLOR=Red]5120[/COLOR]
192.168.2.77:/disk/dbox/aufnahmen on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.2.77)

11264, 11264
8192+0 records in
8192+0 records out
real    2m 16.92s
user    0m 0.18s
sys     0m 12.07s
[COLOR=Red]3737[/COLOR]
8192+0 records in
8192+0 records out
real    1m 37.71s
user    0m 0.15s
sys     0m 7.81s
[COLOR=Red]5224[/COLOR]
192.168.2.77:/disk/dbox/aufnahmen on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.2.77)

12288, 12288
8192+0 records in
8192+0 records out
real    2m 19.63s
user    0m 0.27s
sys     0m 11.95s
[COLOR=Red]3657[/COLOR]
8192+0 records in
8192+0 records out
real    1m 43.36s
user    0m 0.25s
sys     0m 7.90s
[COLOR=Red]4923[/COLOR]
192.168.2.77:/disk/dbox/aufnahmen on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.2.77)

16384, 16384
8192+0 records in
8192+0 records out
real    2m 16.75s
user    0m 0.27s
sys     0m 11.67s
[COLOR=Red]3737[/COLOR]
8192+0 records in
8192+0 records out
real    1m 34.32s
user    0m 0.29s
sys     0m 8.28s
[COLOR=Red]5446[/COLOR]
192.168.2.77:/disk/dbox/aufnahmen on /mnt/filme type nfs (rw,v3,rsize=16384,wsize=16384,soft,udp,nolock,addr=192.168.2.77)

24576, 24576
8192+0 records in
8192+0 records out
real    2m 12.35s
user    0m 0.26s
sys     0m 12.17s
[COLOR=Red]3849[/COLOR]
8192+0 records in
8192+0 records out
real    1m 34.89s
user    0m 0.23s
sys     0m 8.08s
[COLOR=Red]5389[/COLOR]
192.168.2.77:/disk/dbox/aufnahmen on /mnt/filme type nfs (rw,v3,rsize=16384,wsize=16384,soft,udp,nolock,addr=192.168.2.77)

32768, 32768
8192+0 records in
8192+0 records out
real    2m 10.42s
user    0m 0.27s
sys     0m 12.71s
[COLOR=Red]3938[/COLOR]
8192+0 records in
8192+0 records out
real    1m 41.19s
user    0m 0.19s
sys     0m 7.30s
[COLOR=Red]5019[/COLOR]
192.168.2.77:/disk/dbox/aufnahmen on /mnt/filme type nfs (rw,v3,rsize=32768,wsize=32768,soft,udp,nolock,addr=192.168.2.77)
mit unslung hatte ich in etwa solche Werte:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
8192, 8192
8192+0 records in
8192+0 records out
real    1m 0.28s
user    0m 0.30s
sys     0m 10.49s
[COLOR=Red] 8393[/COLOR]
8192+0 records in
8192+0 records out
real    1m 9.05s
user    0m 0.28s
sys     0m 8.43s
[COLOR=Red]7529[/COLOR]
192.168.179.30:/Aufnahme on /mnt/record type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.179.30)
Gruß
Maestrox

Anzeigen

maestrox

Schüler

  • »maestrox« ist der Autor dieses Themas

Beiträge: 54

Firmwareversion / your current Firmware: originale Firmware 2.3r24

  • Nachricht senden

2

Donnerstag, 12. März 2009, 19:35

AW: NFS viel zu langsam

hat den niemand eine idee oder einen tip?

Anzeigen

maestrox

Schüler

  • »maestrox« ist der Autor dieses Themas

Beiträge: 54

Firmwareversion / your current Firmware: originale Firmware 2.3r24

  • Nachricht senden

3

Freitag, 13. März 2009, 19:29

AW: NFS viel zu langsam

habe heute noch einmal getestet.
die aufnahmen werden so ca 125 - 500 MB groß.
mehr habe ich bis jetzt nicht geschafft dann kommt die meldung, dass die daten nicht schnell genug geschrieben wurden.

4

Freitag, 13. März 2009, 20:48

AW: NFS viel zu langsam

Ich gehe mal davon aus, dass Du NFS unter Debian mit den gleichen Parametern betreibst wie zuvor unter Unslung. Dann dürfte ein wesentlicher Grund sein, dass unter Debian einfach erheblich mehr Dienste standardmäßig laufen als unter Unslung.
Folgender Links könnte helfen, den Speicherhunger von Debian zumindest einzuschränken:
http://www.cyrius.com/debian/nslu2/reducing-memory.html
Zudem wäre es sinnvoll, eventuell vorhandene, aber nicht benötigte Fileserver (z.B. Samba oder Netatalk) zu deaktivieren.
Ich gebe zu, dass ich hier auch etwas im Dunkeln stochere, aber Du müsstest schon genauere Infos liefern:

  • Welche Debian-Version?
  • Was läuft sonst noch auf der Slug?
  • Wird auf eventuelle andere Dienst (Webserver etc.) parallel zum NFS-Zugriff aktiv zugegriffen?


Gruß,

Thomas

PS.: Ich selbst hatte auch mal Debian (Lenny) auf der Slug, aber im Endeffekt war das für meine Zwecke zu fett und träge. Debian-Pakete sind meines Wissens eben nicht für Systeme mit schlapper CPU und wenig RAM optimiert.

maestrox

Schüler

  • »maestrox« ist der Autor dieses Themas

Beiträge: 54

Firmwareversion / your current Firmware: originale Firmware 2.3r24

  • Nachricht senden

5

Freitag, 13. März 2009, 21:35

AW: NFS viel zu langsam

Also,


  • Installiert ist : Linux debian 2.6.18-6-ixp4xx #1 Sat Dec 27 23:27:54 UTC 2008 armv5tel GNU/Linux

auf der slug läuft bis jetzt:


  • openvpn (noch im test, spricht läuft nicht immer)


  • samba (wären der aufnahmen war kein smb zugriff)


  • nfs

Zitat

Wird auf eventuelle andere Dienst (Webserver etc.) parallel zum NFS-Zugriff aktiv zugegriffen?

Wie meinst du das?

gruß
maestrox

6

Samstag, 14. März 2009, 11:10

AW: NFS viel zu langsam

Zitat


Zitat


Wird auf eventuelle andere Dienst (Webserver etc.) parallel zum NFS-Zugriff aktiv zugegriffen?
Wie meinst du das?

Naja, so in etwa wie bei Samba: Wenn Du z.B. parallel einen Apache-Webserver in Betrieb hättest, auf den diverse User gleichzeitig zugreifen, dann wäre eine ansonsten mäßige Performance vorprogrammiert. Das scheint aber nicht der Fall zu sein.
Ob VPN entsprechende Auswirkungen hat, kann ich mangels eigener Erfahrungen mit VPN nicht sagen.
Du könntest testweise versuchen, Samba sowie die damit verbundenen Dienste nmbd und winbind vorübergehend zu stoppen (geht unter Debian recht einfach über das Samba-Webinterface SWAT, Zugriff über http://<IP-Adresse der Slug>:901) und dann noch einmal den Durchsatz prüfen.
Unter http://www.nslu2-linux.org/wiki/Debian/FAQ finden sich noch folgende Hinweise zur Reduzierung des RAM-Bedarfs von Debian:

Zitat


Also the default Debian install has a message transfer agent enabled by default (exim4). If this is not needed consider removing it to free up 8Mbytes of RAM.
Switching the default shell from *bash* to *dash* saves another chunk of memory
Allerdings bezieht sich das aber noch auf Etch, mangels Debian auf meiner Slug kann ich nicht prüfen, ob das noch aktuell ist.

Wie aber oben schon angedeutet, würde ich noch mal über Debian selbst nachdenken. Die riesige Auswahl an Paketen, gute Dokumentation und die EABI-Unterstützung sind natürlich Pro-Argumente, aber für mich hat sich der Umfang der Grundinstallation als Overkill herausgestellt. Gerade die geringe Schreibrate legt nahe, dass eventuell andere Schreibvorgänge parallel laufen - z.B. Zugriff auf Swapspeicher. Das lässt sich zwar wie hier beschrieben minimieren, aber ggf. nicht völlig umgehen. Und wenn Swap sowie NFS-Schreibvorgänge parallel auf den gleichen Datenträger zugreifen, ist ein Performanceeinbruch so sicher wie das Amen in der Kirche.
Wenn Du es bei VPN, NFS und Samba belassen willst, dürften andere Systeme (also z.B. Unslung oder SlugOS) besser geeignet sein, insbesondere, da das neue SlugOS 5.3 beta ebenfalls EABI-Unterstützung und damit bessere Floating-Point-Performance als ältere Varianten bietet.

Gruß,

Thomas

maestrox

Schüler

  • »maestrox« ist der Autor dieses Themas

Beiträge: 54

Firmwareversion / your current Firmware: originale Firmware 2.3r24

  • Nachricht senden

7

Samstag, 14. März 2009, 15:20

AW: NFS viel zu langsam

problem war, dass ich zwar openvpn auf der unslung slug installieren konnte, aber das routing partout nicht funktionieren wollte. frag nicht warum ...
jetzt klappt openvpn aber nfs nicht mehr ^^.
vielleicht ne zweite slug mit unslung nur für nfs?

8

Sonntag, 15. März 2009, 11:18

AW: NFS viel zu langsam

Zitat


vielleicht ne zweite slug mit unslung nur für nfs?
Wenn Du das Geld über hast... Allerdings frage ich mich, ob Du VPN und NFS gleichzeitig brauchst. Zumindest das Abspielen von Video auf der dbox dürfte doch vor allem dann interessant sein, wenn Du zu Hause bist, VPN dagegen wenn nicht. Aber ob's am parallelen Betrieb liegt, wage ich nach meinen neusten Erfahrungen fast zu bezweifeln:
Ich habe gestern etliche Stunden damit verbracht, SlugOS 5.3 zu installieren, einzurichten und zu testen. Resultat: Grottige NFS-Performance (Schreibrate von meiner Settop-Box aus: 0,86 MB/s)! Also zurück zu SlugOS 4.8... hat ja nur eine kleine Ewigkeit gedauert. In diesem Zusammenhang frage ich mich, ob sich EABI (sowol in Debian Lenny als auch in SlugOS 5.3) irgendwie mit NFS beißt. Ich wollte auch gerade bei http://tech.groups.yahoo.com/group/nslu2-linux/messages posten, um die Developer zu erreichen, aber trotz korrekter Anmeldung bei Yahoo nimmt der Server meine Nachricht nicht an :mad:
Sorry, dass ich an dieser Stelle auch mit meinem Latein am Ende bin.

Gruß,

Thomas

maestrox

Schüler

  • »maestrox« ist der Autor dieses Themas

Beiträge: 54

Firmwareversion / your current Firmware: originale Firmware 2.3r24

  • Nachricht senden

9

Sonntag, 15. März 2009, 11:57

AW: NFS viel zu langsam

ich glaube auch nicht, dass openvpn so viel performance in Anspruch nimmt.
Ich habe auch festgestellt, das wenn ich z.B. mit unslung etwas per nfs aufgenommen habe die cpu auslastung gerade mal bei~ 25% lag. Jetzt mit debian bin ich so bei 75-85% bei einer Aufnahme.
Das mit dem debian abspecken ist mir noch nicht so geläufig. Gibt es ein pauschal ein paar überflüssige dienste die viel performance fressen?
wie schalte ich diese ab?

Gruß
Maestrox.

10

Sonntag, 15. März 2009, 16:57

AW: NFS viel zu langsam

Ein paar Möglichkeiten habe ich ja oben bereits verlinkt, aber sei's drum:

In /etc/inittab kann folgende Zeile duch ein # am Zeilenanfang deaktiviert werden:
T0:23:respawn:/sbin/getty -L ttyS0 115200 linux
Die Zeile wird nur gebraucht, wenn man per Hardware-Modifikation tatsächlich einen seriellen Anschluss hat. Bei laufendem Betrieb wird die Änderung durch telinit q aktiviert, ansonsten gilt sie ab dem nächsten Neustart.
Sofern Du LVM nicht verwendest, kannst Du /etc/init.d/libdevmapper1.02 editieren: Schreibe exit 0 als neue zweite Zeile in die Datei, damit der Devicemapper nicht geladen wird.
Falls Du IPv6 nicht brauchst, kannst Du auch auf das entsprechende Kernel-Modul verzichten. Dazu schreibst Du in /etc/modprobe.d/blacklist die Zeile
blacklist ipv6
Entsprechend kannst Du für andere Kernel-Module vorgehen, von denen Du sicher weißt, dass Du sie nicht brauchst.
Eventuell stehen in /etc/inetd.conf Services, die Du ncht brauchst. Auskommentieren hilft.
Außerdem kannst Du eventuell vorhandene, aber nicht benötigte Pakete deinstallieren bzw. deaktivieren.
(Quelle bis hier her: http://www.cyrius.com/debian/nslu2/reducing-memory.html )
http://www.nslu2-linux.org/wiki/Debian/FAQ empfiehlt zudem, nicht benötigte Fileserver zu deaktivieren. Das dürfte in Deinem Fall Netatalk (für Apple) sein. Eine genaue Anweisung steht dort leider nicht, da das Vorgehen für NFS beschrieben wird. Im Prinzip geht es aber darum, das/die Netatalk-spezifische(n) Startscript(e) zu deaktivieren, indem man
/etc/rc2.d/S
<XY><irgendwas_mit_netatalk> in /etc/rc2.d/K<XY><irgendwas_mit_netatalk> umbenennt. Wie das/die Script(e) genau heißen, kann ich leider nicht sagen, da ich eben kein Debian installiert habe. Kuck einfach mal in /etc/rc2.d nach - es dürfte sich um ein oder zwei Scripte handeln.
Falls Du exim4 nicht brauchst, kannst Du das auch rauswerfen. Auch die Bash ist ein Ressourcenfresser. Falls Du ohne leben kannst, könnte Dash genug sein.

Auf die Gefahr hin, dass ich mich wiederhole: Andere Firmware-Varianten sind von vornherein erheblicher schlanker als Debian. Ich habe jetzt wieder SlugOS 4.8 drauf, bei dem dieses ganze Feintuning (bis auf den ersten Punkt) nicht nötig ist, weil der ganze Kram gar nicht erst installiert wird. Im Gegensatz zu Unslung bekommt man aber ein ziemlich typisches Linux-System mit 2.6er-Kernel und ohne den Krampf mit den Diversion-Scripts. Es fährt flott hoch (System auf einem 2GB-USB-Stick, zwei Platten (1TB+250GB) am Hub am anderen USB-Port), Samba und NFS tun genau das, was ich erwarte und OpenVPN ist auch als Paket verfügbar. Ein wenig Lektüre auf http://www.nslu2-linux.org/wiki/SlugOS/HomePage hilft dabei, die Eigenheiten dieses Systems zu meistern - zu nennen wären der Unterschied zwischen ipkg und ipkg-opt sowie die etwas fummelige Einrichtung internationaler Zeichensätze, damit Samba die Umlaute nicht vermurkst

So, jetzt bin ich erstmal weg, weil ich live sehen will, wie Werder Stuttgart wegputzt ;).

Gruß,

Thomas


11

Sonntag, 15. März 2009, 18:01

AW: NFS viel zu langsam

Zitat von »maestrox;35002«

ich glaube auch nicht, dass openvpn so viel performance in Anspruch nimmt.

Öhm, VPN braucht keine Performance? Je nach Verschlüsselungsalgorithmus braucht man nen 1+ GHz Prozessor um 100 Mbit/s Durchsatz zu bekommen. Selbst bei DSL-Transferraten geht die NSLU2 bei OpenVPN ziemlich in die Knie.

Zitat von »maestrox;35002«


Ich habe auch festgestellt, das wenn ich z.B. mit unslung etwas per nfs aufgenommen habe die cpu auslastung gerade mal bei~ 25% lag. Jetzt mit debian bin ich so bei 75-85% bei einer Aufnahme.

Unslung benutzt die NSLU2-CPU im Big Endian Modus, in diesem Modus werden auch Netzwerkübertragungen gemacht. Debian/NSLU2 benutzt jedoch den Little Endian Modus, so daß bei jeder Netzwerkübertragung nocheinmal ein Byteswap durchgeführt werden muß, was der Performance nicht gerade zuträglich ist. SlugOS (auch im Big Endian Modus) ist da wohl die bessere Wahl. Früher gab es auch mal eine Debian Variante im Big Endian Modus, aber ich habe keine Ahnung, ob die noch gepflegt wird. http://www.debonaras.org/

Zitat von »maestrox;35002«


Das mit dem debian abspecken ist mir noch nicht so geläufig. Gibt es ein pauschal ein paar überflüssige dienste die viel performance fressen?

Schau doch einfach mal bei der NFS-Aufnahme mit "top" nach, welche Prozesse die meiste Performance verbraten. Wenn du diese identifiziert hast, kann du mit

Quellcode

1
dpkg -S prozessname
rausfinden, zu welchem Paket diese gehören. Falls es ein Dienst ist, der beim Systemstart geladen wird (aus /etc/init.d), gibt es die Möglichkeit, per

Quellcode

1
update-rc.d skriptname remove
den Start zu verhindern.

Gruß,
Patrick

maestrox

Schüler

  • »maestrox« ist der Autor dieses Themas

Beiträge: 54

Firmwareversion / your current Firmware: originale Firmware 2.3r24

  • Nachricht senden

12

Sonntag, 22. März 2009, 11:41

AW: NFS viel zu langsam

hey,
war lange nicht mehr online, deswegen hatte ich noch nicht geantwortet.
Also ich meinte eingentlich wenn openvpn im idle ist, also ohne eine bestehende verbindung.
Wenn eine verbindnug steht sieht es natürlich anderes aus, aber während meiner aufnahmen war das nie der fall.
ich werde es heute abend noch einmal versuchen und dann mal deine tips befolgen.

gruß
maestrox

maestrox

Schüler

  • »maestrox« ist der Autor dieses Themas

Beiträge: 54

Firmwareversion / your current Firmware: originale Firmware 2.3r24

  • Nachricht senden

13

Sonntag, 22. März 2009, 12:24

AW: NFS viel zu langsam

ich nehme ja auf eine hdd auf die an der slug angeschlossen ist.

Quellcode

1
2
3
4
5
6
7
Disk /dev/sdc: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               2       24321   195350400    f  W95 Ext'd (LBA)
/dev/sdc5               2       24321   195350368+  83  Linux
Habe die HDD mit Partition Magic formatiert. allerdings sieht es so aus als wäre die ext2 partition in einer anderen Partition.
kann dadurch die langsame Geschwindigkeit kommen?
Manchmal fliegt nämlich die hdd aus dem system raus. dann muss die die hdd wieder abklemmen und dann kann ich sie erst wieder mounten.

14

Samstag, 18. April 2009, 18:46

AW: NFS viel zu langsam

Zitat von »maestrox;34953«

Hi,
ich habe auf meiner slug Debian/NSLU2 (armel) 5.0 Stable Release am laufen.

Ich habe wahrscheinlich dasselbe Problem. Mit etch (4.0) ging es noch einwandfrei. Nach dem Update auf Lenny (5.0) fing das Problem an.

Bei mir tritt folgendes Phänomen auf:
Von der dbox aus lässt sich NFS auf der nslu2 nur noch mit einer r/wsize von max. 8192 mounten, egal was ich bei mount-Befehl (oder in der Konfig) angebe:

Quellcode

1
2
3
~ # mount -t nfs -o rw,soft,udp,nolock,async,rsize=32768,wsize=32768 192.168.178.10:/data/tv /mnt/filme
~ # mount
192.168.178.10:/data/tv on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.178.10)
Wenn ich das Verzeichnis auf der nslu2 von einem anderen Debian-PC aus mounte, kann ich größere r/wsize verwenden. Wenn ich auf der dbox ein Verzeichnis des Debian-PC mounte, ebenfalls.

Das Problem tritt also nur zwischen der dbox und der nslu2 auf.
Auf der dbox habe ich das ng-return-Image (1.8). Downgrade auf 1.7 getestet ohne Erfolg.

UdoSW

15

Montag, 20. April 2009, 18:44

AW: NFS viel zu langsam

Ich hatte auch NFS-Probleme, allerdings nach der Umstellung auf SlugOS 5.3. Hintergrund war, dass meine USB-HDDs, die ich zuvor per fstab von Hand eingebunden hatte, nun per udev gemountet wurden und zwar mit der Option "sync". mount sollte Auskunft darüber geben, ob das bei Euch auch der Fall ist. Unter SlugOS ließ sich durch Einträge in /etc/udev/mount.blacklist festlegen, für welche Geräte udev nicht zuständig sein soll (bei mir sdb und sdc). Für diese permanent verbundenen USB-HDDs mit meinem Streamingarchiv gilt nun wieder die per fstab gesetzt Option async und NFS läuft wieder so flott wie zuvor.
Ist etwas Recherche auf Euren Slugs wert.
Die Sache mit rsize/wsize 8192 liegt m.E. daran, ob beim Kompilieren des Kernels die Option für andere Größen gesetzt wurde. 8192 ist der Default-Wert. Ich hätte auch gerne 32k, aber dafür setze ich jetzt keinen Crosscompiler auf.

Gruß,

Thomas

Social Bookmarks