10 replies to this topic

[knud66]

root@dreambox ~ # mount
/dev/root on / type squashfs (ro)
none on /dev type devfs (rw)
/proc on /proc type proc (rw,nodiratime)
devpts on /dev/pts type devpts (rw)
/dev/mtdblock/1 on /var type jffs2 (rw,noatime)
none on /tmp type ramfs (rw)
/dev/mtdblock/1 on /var_flash type jffs2 (rw,noatime)
192.168.1.1:/VOL on /hdd type nfs (rw,v3,rsize=8192,wsize=8192,hard,udp,nolock,addr=192.168.1.1)
root@dreambox ~ # ls hdd
ls: hdd: Permission denied
root@dreambox ~ # ls /hdd
ls: /hdd: Permission denied

Dit is mijn resultaat van een middagje knutselen aan een dreambox die een nfs mount wil maken aan mijn server. De server exporteert het volume als volgt (showmount -e server op een solaris machine)

# showmount -e server
export list for server:
/VOL (everyone)

En natuurlijk is het ip-adres wat in de lijst staat van de dreambox mount hetzelfde als het naampje 'server' in de DNS.

Edit: Nog even wat aanvullende info: de server is een NetWare oes machine en de dreambox is een 500 met Garnet.


Waarom krijg ik een permission denied op een ls aanvraag? Wie weet er raad? Waarom kent de dreambox niet het commando 'showmount' ?

[knud66]

Even nog wat meer pogingen:

root@dreambox ~ # mount -t nfs -rw -nolock 192.168.1.1:/VOL /hdd   
root@dreambox ~ # mount
/dev/root on / type squashfs (ro)
none on /dev type devfs (rw)
/proc on /proc type proc (rw,nodiratime)
devpts on /dev/pts type devpts (rw)
/dev/mtdblock/1 on /var type jffs2 (rw,noatime)
none on /tmp type ramfs (rw)
/dev/mtdblock/1 on /var_flash type jffs2 (rw,noatime)
192.168.1.1:/VOL on /hdd type nfs (rw,v3,rsize=32768,wsize=32768,hard,udp,lock,addr=192.168.1.1)
root@dreambox ~ # ls /hdd 
ls: /hdd: Permission denied
root@dreambox ~ # umount /hdd
root@dreambox ~ # mount
/dev/root on / type squashfs (ro)
none on /dev type devfs (rw)
/proc on /proc type proc (rw,nodiratime)
devpts on /dev/pts type devpts (rw)
/dev/mtdblock/1 on /var type jffs2 (rw,noatime)
none on /tmp type ramfs (rw)
/dev/mtdblock/1 on /var_flash type jffs2 (rw,noatime)
root@dreambox ~ # mount -t nfs -rw -nolock -o 192.168.1.1:/VOL /hdd
Can't find /hdd in /etc/fstab

Nu zou er iets in '/etc/fstab' moeten staan. Volgens mij heb ik nog meer uit te zoeken dan tot nogtoe. de optie '-o' geeft dus een melding over 'fstab'. Iemand nog met meer informatie?

Edit: Is het uberhaupt mogelijk om fstab in /etc te bewerken?? Volgens mij wordt alles geweigerd door vi. of welke andere editor dan ook. Had zelf ondertussen uitgevonden hoe de tekst zou moeten luiden in fstab maar kan deze dus niet invoegen....

Voor geinteresseerde de informatie heb ik geleerd van http://www.die.net/d...n5/fstab.5.html en de regel die zou moeten luiden zoiets als

192.168.1.1:/VOL /hdd nfs rw,nolock,rsize=8192,wsize=8192,soft,intr,nfsvers=3

die ik dus niet in fstab kan krijgen. Grrr.

[pieterg]

schrijven in fstab kan alleen als je een rw rootfs hebt (dus met een openembedded image).
Verder is dat niet nodig, fstab wordt alleen eenmalig tijdens mounten geraadpleegd. Je kan ook gewoon de mount vanuit een opstartscript uitvoeren, als je fstab niet kunt editen.

[dAF2000]

Of gewoon vanuit Enigma.
Die permission denied heb ik wel 'ns gehad met nfs geloof ik. Ik weet de details niet meer maar ik dacht dat 't kwam door een rechtenkwestie. Probeer eens op de server alles op die mount op chmod 777 te zetten.

[knud66]

Zal ik eens gaan proberen, ik was in de veronderstelling doordat de showmount commando everyone teruggaf de impressie dat de rechten dus ook al volledig waren. zou heel erg goed kunnen dat het anders is, voor een beschrijfbare fstab heb ik dus een multiboot nodig en dan is het nog maar de vraag of op dat moment de juiste fstab gelezen wordt.

Bedankt voor de info. Ga weer verder experimenteren

[knud66]

Ben weer eens verder gegaan met dit experiment, het bleek dat er inderdaad nog wat rechten te regelen waren op de server. Nadat de rechten op de server gezet waren was het geen enkel probleem meer om de mount te maken zoals hierboven al was omschreven, rest nog een vraagje: welke manier van mounten met een extern systeem is eigenlijk de beste, nfs had in eerste instantie mijn voorkeur omdat dat uit de unix omgeving kwam, echter het is een udp verbinding dus het kan heel erg goed zijn dat er pakketten verloren gaan tijdens het transport, dat kan toch niet echt een positief punt zijn.

[dAF2000]

Ik wist niet dat nfs udp was. Ik gebruik vanwege "browsebaarheid" gewoon cifs terwijl ik nauwelijks Windows gebruik (voornamelijk Linux en NetBSD).

[WanWizard]

Of UDP een probleem is hangt er maar helemaal van af...

Voor realtime protocollen is UDP normaal geen probleem. Aan retries en handshaking heb je toch niet zo veel, als je pakket dan met vertraging binnen komt. En hickup heb je dan toch te pakken.

Andersom is het natuurlijk ook zo dat op een goed netwerk je dat soort problemen niet hebt, wat dan ook automatisch betekent dat TCP ook geen probleem mag zijn.

Als je echter waarde hecht aan een correcte overdracht (voor opnames, of data die niets met streaming te maken geeft), is wellicht de (mogelijke) onbetrouwbaarheid van UDP minder handig...

[knud66]

Ik ga er vooralsnog vanuit dat mijn netwerkje betrouwbaar is. Moet nog even kijken naar het resultaat van een proefopname van een dreambox 500 naar de nfs-share. Echter als ik de opname probeer terug te spelen dan krijg ik een bevroren enigma. Kan te maken hebben met het rechtenmasker van de share, deze is '022' wat betekend dat de share alle bestanden op de share de rechten 755 toekent (777 - 022). Weet niet of dat voor de dreambox een probleem vormt, ikzelf denk niet echt.

[pieterg]

met udp gaan er gewoon pakketten verloren, zelfs op het meest betrouwbare netwerk.
Maar omdat nfs zelfs checks, retries en correcties uitvoert, in een extra layer bovenop UDP, is nfs over udp in de regel toch betrouwbaar. (je kan overigens per mount instellen of je tcp of udp wilt gebruiken)

[Sjaaky]

Echter als ik de opname probeer terug te spelen dan krijg ik een bevroren enigma.

Ik heb ook eens zitten spelen met nfs en heb hetzelfde geconstateerd. Blijkt dat te grote udp packets richting een dm500 voor een flinke hoeveelheid packetloss zorgen, en daarmee voor zeer instabiel/traag gedrag bij het gebruik van de nfs mount.
Ik heb de rsize zelf op 4096 staan, dat levert bij mij een prima performance op. Ongeveer 32MBit/s schrijven en 25MBit/s lezen. Dit is niet heel nauwkeurig omdat ik meet met een resolutie van secondes

date&&dd of=/dev/null if=dvd/test bs=100000 count=320&&date

Het is beter dan wat ik met cifs haal (maar toch gaat opnemen met cifs beter, :smt102). Mijn mount commando:

mount 192.168.1.6:/mnt/dvd /hdd/dvd -o rw,soft,udp,nolock,rsize=4096,wsize=32768

Onder linux met ping -f is het ook goed te zien:

# ping -c 1000 -f -s 10000 192.168.1.5
1000 packets transmitted, 1000 received, 0% packet loss, time 4071ms
# ping -c 1000 -f -s 11000 192.168.1.5
1000 packets transmitted, 1000 received, 0% packet loss, time 4400ms
# ping -c 1000 -f -s 12000 192.168.1.5
1000 packets transmitted, 1000 received, 0% packet loss, time 4818ms
# ping -c 1000 -f -s 13000 192.168.1.5
1000 packets transmitted, 999 received, 0% packet loss, time 11996ms
# ping -c 1000 -f -s 14000 192.168.1.5
1000 packets transmitted, 964 received, +15 errors, 3% packet loss, time 19129ms
# ping -c 1000 -f -s 15000 192.168.1.5
1000 packets transmitted, 666 received, 33% packet loss, time 16190ms
# ping -c 1000 -f -s 16000 192.168.1.5
1000 packets transmitted, 653 received, 34% packet loss, time 16170ms

Ik denk dat een te grote rsize ervoor zorgt dat de 'server' te efficient de dreambox kan overspoelen met packets. De dreambox heeft niet genoeg tijd om deze te verwerken. Uit bovenstaande ping resultaten zou je kunnen concluderen dat rsize=8192 ook goed moet gaan. Maar dat levert bij mij maar 8Mbit/s op, in vergelijk met 32Mbit/s bij rsize=4096, waardeloos dus. Ik denk dat het afhankelijk is van hoe snel de server is en hoe goed deze in staat is de dream te overspoelen met packets. Een van de features van tcp is flowcontrol, juist om dit soort problemen te voorkomen. tcp houdt rekening met hoe snel de ontvanger data kan verwerken. Dus

mount 192.168.1.6:/mnt/dvd /hdd/dvd -o rw,soft,tcp,nolock,rsize=32768,wsize=32768

werkt dan ook prima, maar is net iets langzamer bij mij dan de udp variant. Wellicht dat het zich beter gedraagt bij verschillende belastingen van dreambox en server, maar dat is voor een andere keer