atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: 1ST1 am Do 14.12.2017, 21:07:38
-
Hallo, ich habe unter EasyMiNT NFS eingerichtet, und zwar mit einem Eintrag in /etc/fstab und auf der Gegenseite habe ich einen NFS-Dienst unter Windows 7 laufen, der hier: http://sourceforge.net/projects/winnfsd
Ich kann grundsätzlich auf das NFS-Laufwerk zugreifen und auch Dateien runter und rauf kopieren, was schonmal genial ist. Allerdings gibt es auf dem NFS-Laufwerk Ordner, in dem viele Dateien liegen, genauer meine gesamte Dateisammlung für die Atari ST Rechner. Das Problem dabei ist, ab ein paar hundert Einträgen in einem Ordner wird nichts mehr angezeigt, sowhl in einem Fenster von Thing als auch an der Shell (ls -l, ll, etc.) Sicher kann man das umräumen und besser strukturieren, aber es betrifft leider auch Ordner, die so sein müssen, z.B. eine Anwendung mit einem aufwändigen Dateisammelsurium, 510 Dateien in einem Ordner. Der Ordner existiert bereits auch auf einer BGM-Partition meines TT und von dort wird der Ordner mit allen Dateien auch unter EasyMiNT / Thing / Shell vollständig angezeigt.
Könnt ihr das bitte mal gegenchecken, mit einem anderen NFS-Server?
Im zweiten Schritt müsste ich dann wohl nochmal einen dritten NFS-Server für Windows ausprobieren, oder es gibt vielleicht ein bekanntes Problem mit dem MiNT-Kernel vomn EasyMiNT 1.90 oder dem NFS.XIF, was sich durch einfachen Austausch beheben könnte.
-
MiNT 1-19-cur mit Linux (Ubuntu 16) als NFS-Server:
# cd /nfs/thinkpad/testdir
# for i in $(seq 1 2000); do touch file$i; done
# ls -1 | wc -l
2000
... an MiNT liegt's nicht.
-
Zu wenig RAM im TT? :o
-
Zu wenig RAM im TT? :o
Glaube ich nicht, sonst könnte er das Verzeichnis mit 510 Dateien auf der TOS-Partition nicht anzeigen. Es sind auch 16 MB TT-RAM da (und ThunderStorm muss noch eingebaut werden).
@mfro: Ist MiNT 1-19-cur die Version die in EasyMiNT 1.90 steckt, oder wo bekomme ich die her? (Brauche ich dann nur MiNT*.PRG im Auto-Ordner auszutauschen?)
-
@mfro: Ist MiNT 1-19-cur die Version die in EasyMiNT 1.90 steckt, oder wo bekomme ich die her?
Keine Ahnung, ich benutze EasyMiNT nicht ("uname -r" heisst hier das Zauberwort); aber das spielt auch gar keine Rolle - mit 1.18 geht's genauso.
(Brauche ich dann nur MiNT*.PRG im Auto-Ordner auszutauschen?)
Nein. Du musst zusätzlich (praktisch) alles tauschen (bzw. dazukopieren), was in c:\mint steckt.
-
Bei mir mit einem 112GB Verzeichnis für den Atari das auf einem macOS Rechner liegt gibt es kein Problem.
Das MiNT aus dem EasyMiNT Paket ist ein normales FreeMiNT 1-19-CUR aber schon älter. EasyMiNT ist nur ein Installer für die SparMiNT UNIX RPM Pakete. Wenn du den MiNT Kernel aktuell halten willst nimm den trunk -> https://freemint.github.io
Ich denke das Problem liegt an der Windows Software.
-
Und ggf. musst Du in der "/etc/ttytab" den Pfad zu XaAES anpassen. Alternativ kannst Du aber auch den XaAES-Alias neu anlegen, der in der letzten Zeile der ttytab steht:
# /etc/ttytab
# Prinzipiell läuft auf der console ein normaler getty
#
# Es darf nur einer der Einträge aktiv sein!
#
console "/c/mint/1-16-cur/xaaes/xaloader.prg" tw52 on secure
#console "/usr/sbin/getty console" vt52 on secure
#console "/usr/bin/n_aes" tw52 on secure
#console "/usr/bin/xaaes" tw52 on secure
Wenn Du den Alias nutzt, musst Du bei einem Wechsel der MiNT-Version nicht immer an die ttytab ran und kannst stattdessen immer den Alias erneuern. Aber mach mal wie Du willst. ;D
-
Wenn er bei 1-19-cur bleibt sollte das ganze so laufen ...
-
Wenn er bei 1-19-cur bleibt sollte das ganze so laufen ...
Kommt drauf an ob der Name des Ordners sich geändert hat, in dem sich XaAES und die Treiber befinden. Wenn man den Trunk läd sollte sich nichts ändern. Wenn man aber die 68020er Version läd, hat der Ordner interessanterweise eine andere Benennung.
-
Der trunk ist ja immer die aktuelle Snapshot Version. Beim helmut build ist das XaAES neuer aber es fehlen viele Sachen die man aus dem trunk dann braucht. Bei beiden bleibt es bei c:\mint\1-19-cur\xaaes ...
-
Boah, ist das kompliziert... *kopfrauch*
Ich werd erst mal sehen ob ich einen anderen NFS-Server finde.
-
Wenn du nur MiNT/XaAES Aktuell halten willst einfach mint030.prg im Autoordner und alles was im mint\1-19-cur Ordner ist austauschen. Das ist alles ...
Deine mint.cnf und deine xaaes.cnf musst/kannst du ja behalten.
-
Das hört sich doch schon besser an. Welche Version sollte ich mal testen? (Link?)
-
Wenn du den MiNT Kernel aktuell halten willst nimm den trunk -> https://freemint.github.io
Da ...
-
Dein NFS-Problem behebt das aber nicht ...
-
Was, der neue Kernel oder der andere NFS-Server? (Wobei ich noch keine grundsätzlich funktionierende Alternative habe)
-
Kannst du nicht mal als Test ob es am Windows NFS Dienst liegt auf einem PC ein Ubuntu oder Debian Linux aufspielen?
-
In die Richtung sollen meine Versuche gehen, folgende Ideen habe ich inzwichen eingesammelt:
1. Auf meinem Windows "Server" Cygwin installieren, da ist auch ein NFS-Server dabei. Ich weiß nur noch nicht, wie ich den automatisch starte, wenn der Rechner neu bootet.
2. Das wollte ich gestern Abend machen. Ich habe zwei IBM Thinkpads als Reserve, auf denen Linux drauf ist. Das eine habe ich mit Linux-Mint in der Bucht geschossen und kenne das Root-PW nicht. Das muss ich also komplett neu installieren, um nfs-Geraffel damit machen zu können. Das Zweite hab ich vor ewigen Zeiten mal mit Ubuntu installiert, konnte damit gestern den iperf Test machen, aber nfs-Zeugs wills per apt-get nicht installieren, da Canotical die entsprechenden Files bereits in dem Repo rausgeschmissen hat, die Ubuntu-Version ist scheinbar schon zu alt und wird nicht mehr unterstützt. Lange Rede, kurzer Sinn, hab gleich mit Debian-ISOs angefangen die runterzuladen. Alle anderen Linux-Distris sind heutzutage sowieso Murks, weil zu viel Kommerz oder Politik dahinter steckt. Naja, gut, Gentoo ausgenommen, aber das ist ja wohl die nerdigste Distri überhaupt.
3. Ich stelle mir irgendwo einen RaPi mit Linux hin. Die Idee ist, von meinem Server die CIFS-Freigabe bei dem reinzumounten und per NFS wieder zu exportieren. Könnte ich zwar auch mit einem der Notebooks machen, aber die brauchen mir dafür zu viel Strom. (Hatte schon überlegt, ob das mein CosmosEx mit erledigen könnte, aber an dem will ich eigentlich nicht basteln.)
4. Weder auf meinen Haupt-PC noch auf mein ständigundimmerbenutz-Mini-Notebook kommt mir die Pinguin-Seuche nicht drauf! Auf den "Server" schon garnicht.
-
Bitte hier beim Thema bleiben, zum Thema Root-Passwort bei Linux/Unix gehts hier lang:
http://forum.atari-home.de/index.php?topic=14022.msg223407#new
-
1ST1: Gibt es hierzu etwas neues? Ich habe derweil meinen TT und einen Falcon ans LAN angeschlossen, was soweit auch prima funktioniert. Es ist ein reines Linux-LAN mit NFS-Freigaben, was seit gut 15 Jahren einwandfrei läuft. Die beiden Ataris mounten die NFS-Freigaben auch, wenn ich aber darauf zugreife, gibt es bei beiden ein "Permission denied".
Die aktuelle Einstellung ist
mount_nfs -v -o rw,rsize=1024,wsize=1024,retrans=10 192.168.1.2:/share /nfs/share
Ich habe auch die Tipps und Hinweise aus https://forum.atari-home.de/index.php?topic=5450.15&topic=5450.15 und http://www.atari-forum.com/viewtopic.php?f=27&t=21328&sid=b469e7a13eccd13ddd334f743338d3ae probiert, erhalte aber immer wieder das selbe Ergebnis.
-
... Die beiden Ataris mounten die NFS-Freigaben auch, wenn ich aber darauf zugreife, gibt es bei beiden ein "Permission denied"...
Das ist ein anderes (in diesem Fall Permission-) Problem. Wie sieht deine /etc/exports auf dem Server aus und mit welcher UID (auf der MiNT-Seite) versuchst Du, auf die NFS-Freigabe zuzugreifen?
-
Ich habe verschiedene Varianten ausprobiert. Die eine ist
/share 192.168.1.0/24(rw,async,no_root_squash,no_subtree_check)
eine andere (auf uid/gid 0 , also root)
/share 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash,anonuid=0,anongid=0)
aber auch mit uid/gid 1001 , das ist der User, als auch mit fsid=1 da (je nach verwendetem Linux) sonst NFS auf Serverseite meckert und diesen Parameter erwartet. Habe aber ebenso mit sync/async und all_squash/no_root_squash in verschiedenen Kombinationen gespielt. Ergebnis war entweder: geht gar nicht (Timeout) oder im besten Fall wieder "Permission denied".
Auf Atari-/Client-Seite habe ich bislang keine IDs angegeben. War in den Dokus auch nicht angegeben, werde es aber auch noch ausprobieren.
War da nicht etwas, dass MiNT gar nur NFSv2 spricht? Denn den Linuxen untereinander ist es Wurscht, ob ich die Mounts per NFSv3 oder NFSv4 anspreche. Funktioniert immer.
-
bei mir funktioniert das:
/home falcon(rw,async,no_subtree_check,insecure,no_auth_nlm,anonuid=1000,anongid=1000,root_squash)
/home firebee(rw,async,no_subtree_check,insecure,no_auth_nlm,anonuid=1000,anongid=1000,root_squash)
/home m5484lite(rw,async,no_subtree_check,insecure,no_auth_nlm,anonuid=1000,anongid=1000,root_squash)
/home m54455(rw,async,no_subtree_check,insecure,no_auth_nlm,anonuid=1000,anongid=1000,root_squash)
uid 1000 ist mein (normaler) Linux-User, dem das exportierte FS gehört. Hostnamen sind bei mir im DNS. exportfs -a nach jeder Änderung nicht vergessen.
-
Hmm, nein, will nicht. Immer noch "Permission denied". Habe dazu jetzt einfach ein neues Verzeichnis angelegt (/test), owner ist 1001:1001, permission ist 777 und Export
/test 192.168.1.0/24(rw,async,no_subtree_check,insecure,no_auth_nlm,anonuid=1001,anongid=1001,root_squash)
Die anderen Linux schlucken auch das klaglos.
Der Vollständigkeit halber sei noch erwähnt, dass ich zwei identische Netzwerkkarten nutze, auf dem TT helmut-19112017 mit ENEC3.XIF, auf dem Falcon freemint-1-19-6b9-020 mit ne2kenec.xif.
Aber auf beiden Ataris/MiNTs das selbe Problem. Auf den Falcon habe ich sowohl mount_nfs (Sparemint), als auch nfsmount.ttp probiert. Kein Unterschied.
Interessant sind halt die Aussagen des NFS-Servers
rpc.mountd[3870]: authenticated mount request from 192.168.1.79:669 for /test (/test)
und
rpc.mountd[3870]: authenticated unmount request from 192.168.1.79:671 for /test (/test)
dass es also prinzipiell funktioniert *rätsel*
exportfs -a nach jeder Änderung nicht vergessen.
Selbstverständlich :)
-
Ich habe solche Probleme unter macOS HighSierra nicht ...
private/etc/eports = /Users/frank/Downloads/Atari -maproot=0:0 -network 192.168.2.0 -mask 255.255.255.0
Mount am Atari über die etc/fstab = 192.168.2.114:/Users/frank/Downloads/Atari /nfs/MacPro nfs rw 0 0
-
...nur mal so in den Raum geworfen, da mein Problem ja vielleicht an meinem MiNT selber liegt:
MiNT liegt auf Laufwerk F: und alles relevante wurde in der mint.cnf per Symlink auf /f/ umgebogen. Das Verzeichnis /nfs aber nicht. Dessen Permissions sind 755 (testhalber auch mal auf 777 gestellt). Ist nichts dorthin gemountet, kann ich auch dorthin zugreifen. Mounte ich (erfolgreich) z.B. nach /nfs/blabla , kann ich weder auf /nfs noch /nfs/blabla zugreifen, da wieder "Permission denied).
Das MiNT ist aus den Sparemint-RPMs gebaut und funktioniert an sich ganz prima. Das einzige, was noch zu meinem orgiastischen Glück fehlt, ist das Netzwerk. Ziel soll NFS (Atari->PC) und rsync sein - dann kann ich bequem Backups machen und Daten austauschen.
-
... Mounte ich (erfolgreich) z.B. nach /nfs/blabla , kann ich weder auf /nfs noch /nfs/blabla zugreifen, da wieder "Permission denied).
Das bedeutet m.E., dass das Mounten prinzipiell funktioniert und der Fehler erst beim realen Zugriffsversuch passiert. Was steht im syslog auf der Linux-Seite?
Dass Du allerdings schon auf /nfs nicht mehr zugreifen kannst, kommt mir seltsam vor. ls -ld /nfs gibt auch schon "permission denied"?
-
Was steht im syslog auf der Linux-Seite?
Das ist es ja. Es gibt, wie bereits oben erwähnt, nur die erfolgreichen mount/unmount Ergebnisse im syslog. Sonst rein gar nichts dazu:
rpc.mountd[3870]: authenticated mount request from 192.168.1.79:669 for /test (/test)
und
rpc.mountd[3870]: authenticated unmount request from 192.168.1.79:671 for /test (/test)
ls -ld /nfs gibt auch schon "permission denied"?
Nein, das geht. Ausgabe ist "drwxr xr x 1 root root 0 Jan 9 2017 /nfs"
Ein ls -ld /nfs/test allerdings wieder ein "permission denied".
Ich denke, ich werde mal eine ubuntu-VM zum testen aufziehen; die meisten, die von Erfolg berichteten, hatten ein Ubuntu als NFS-Server laufen. Ich habe hier überall Arch-Linux. Vielleicht gibt es dann etwas anderes/neues zu berichten...
-
Hm ... irgendwie scheint das jeder ein klein wenig anders zu machen mit den NFS-Freigaben. Bei mir sieht die "exports" in Mac OS 10.5.8 so aus:
/Volumes/Daten/Music -ro -mapall=nobody -alldirs -network 192.168.2.0 -mask 255.255.255.0
/Volumes/Filme/Filme -ro -mapall=nobody -alldirs -network 192.168.2.0 -mask 255.255.255.0
/Volumes/Daten/Transfer -rw -mapall=nobody -alldirs -network 192.168.2.0 -mask 255.255.255.0
Funktioniert super. Ich kann von meinem Milan aus auf die Freigaben ohne Probleme zugreifen.
...nur mal so in den Raum geworfen, da mein Problem ja vielleicht an meinem MiNT selber liegt:
MiNT liegt auf Laufwerk F: und alles relevante wurde in der mint.cnf per Symlink auf /f/ umgebogen. Das Verzeichnis /nfs aber nicht. Dessen Permissions sind 755 (testhalber auch mal auf 777 gestellt). Ist nichts dorthin gemountet, kann ich auch dorthin zugreifen. Mounte ich (erfolgreich) z.B. nach /nfs/blabla , kann ich weder auf /nfs noch /nfs/blabla zugreifen, da wieder "Permission denied).
Das MiNT ist aus den Sparemint-RPMs gebaut und funktioniert an sich ganz prima. Das einzige, was noch zu meinem orgiastischen Glück fehlt, ist das Netzwerk. Ziel soll NFS (Atari->PC) und rsync sein - dann kann ich bequem Backups machen und Daten austauschen.
Du meinst jetzt, dass "F" Deine Unix (EXT2)-Partition ist? Meines Wissens wird der "NFS"-Ordner nur auf "U" angelegt von MiNT. Umbiegungen sind da nicht nötig bzw. vielleicht sogar schädlich? Ich habe an den Zugriffsrechten des "NFS"-Ordners auch nie was geändert. Was das angeht bin ich eh ein Schisser. ???
Anbei mal ein Foto der Zugriffsrechte meines "NFS"-Ordners.
-
Ach wie gut, dass ich noch eine ubuntu-VM herumliegen hatte. Sogar noch recht aktuell! Also flott auf den tagesaktuellen Stand gebracht, NFS dazu gepackt, Falcon angeflanscht und - was soll ich sagen: ES GEHT! Da brat mir doch einer eine Fledermaus!
Also werde ich nun anfangen zu schauen, wo denn bitteschön im Detail ein Unterschied in den NFS-Implementierungen Ubuntu/ArchLinux ist... *stöhn* Ich werde berichten :)
Einstweilen wieder einmal Dankeschön an alle Beteiligten für die seelische Unterstützung!
-
Hm ... irgendwie scheint das jeder ein klein wenig anders zu machen mit den NFS-Freigaben.
Jo, aber das sollte im Großen und Ganzen ja auch nichts ausmachen. Hauptsache, die Parameter passen in etwa an die "örtlichen Gegebenheiten".
Du meinst jetzt, dass "F" Deine Unix (EXT2)-Partition ist? Meines Wissens wird der "NFS"-Ordner nur auf "U" angelegt von MiNT.
Guter Einwand und richtig erkannt :) Genau so ist es.
Umbiegungen sind da nicht nötig bzw. vielleicht sogar schädlich? Ich habe an den Zugriffsrechten des "NFS"-Ordners auch nie was geändert. Was das angeht bin ich eh ein Schisser. ???
Ich denke auch, dass man besser nicht weiter an /nfs herumfummeln, umbiegen o.ä. sollte. Versuchshalber hatte ich dessen Permission ja auf 777 gesetzt, aber zumindest nach einem Reboot des Atari ist der Ordner von alleine wieder auf 755.
-
So, erste Ergebnisse:
1. Ja, MiNt nutzt (derzeit) NFSv2
2. NFSv2 ist Baustelle bei ArchLinux https://wiki.archlinux.org/index.php/NFS#NFSv2_compatibility . Per Default ist es AUS, aber ich bekomme es momentan nicht eingeschaltet.
3. Bei Debian (zumindest Stretch) ebenso, aber dort war Abhilfe einfach: https://lists.debian.org/debian-kernel/2017/07/msg00393.html
Somit ist das Thema für mich gelöst, denn solange es mit dem Debian klappt, reicht mir das sogar *freu*
Ich denke aber, dass das Thema NFSv2 bei Ubuntu kurz über lang bei einem der neueren Releases ebenfalls wieder auf den Tisch kommt, denn dann kommt ein neueres nfs-utils zum Einsatz und dann dürfte Abhilfe ebenso wie bei Debian Stretch möglich sein.
-
Ich bin noch nicht weiter gekommen, mein Server ging am 24.12 kaputt (Elkos auf dem Mainboard) und Ersatz (ein FSC Esprimo-PC mit gleicher Typenbezeichnung und folglich identischem Board) trudelte erst am letzten Samstag wieder ein, läuft erst jetzt wieder und noch keine Zeit gehabt, die Alternativen zu testen...
-
Ich bin noch nicht weiter gekommen, mein Server ging am 24.12 kaputt [...]
Oh, mein Beileid! Aber wir haben ja jetzt prima Infos zusammen, so dass wir das sicherlich auch bei Dir zum laufen bekommen werden!
-
[offtopic]
Naja der "Server" geht ja wieder, ist aber komischerweise etwas zickig, was den zusätzlichen SATA-Controller angeht, sobald da Platten dran hängen (was ja eigentlich SInn der Sache sein sollte) hängt das BIOS vor dem Booten. Mein momentaner Workarround: Die zwei SATA Platten erst anstöpseln, wenn Windows anfängt zu booten. SATA ist ja Plug&Play... Scheinbar hat das ESPRIMO-BIOS Probleme mit zusätzlichen Platten an Extra-Controllern (hab 3 verschiedene ausprobiert, ohne Platten an dem Controller bootet er). Ist aber shice, muss mir da noch was anderes einfallen lassen. Nur das neueste BIOS hat der Esprimo schon, der Alte muss ein anderes BIOS gehabt haben... (in dem Rechner sind insgesamt 5 große Platten drin, plus eine kleine Systemplatte)
[/offtopic]
-
Mein momentaner Workarround: Die zwei SATA Platten erst anstöpseln, wenn Windows anfängt zu booten. SATA ist ja Plug&Play...
Plug & play ist SATA schon, Hot-plug dagegen nur, wenn das explizit unterstützt wird.
-
Keine Sorge, es klappt.
-
Kleiner Nachtrag: Ich war mit der Übertragungsrate unzufrieden und habe mal ein bisschen an den mount-Einstellungen geschraubt. Vorlage dafür ist http://nfs.sourceforge.net/nfs-howto/ar01s05.html
Ergebnis ist, dass die in den vielen Dokus angegebene rsize/wsize -Größe von 1024 für den Popo ist. Zumindest bei mir; vielleicht ist das aber auch der Vergangenheit geschuldet, als man noch 10- oder gar schon 100MBit hatte. Heute dürfte ja 1000MBit das Mindeste sein, was man laufen hat.
Die Werte sind wie folgt:
time dd if=/dev/zero of=/nfs/test/testfile bs=16k count=2048 # 32MB
# wsize=1024 11min17
# wsize=2048 08min36
# wsize=4096 07min20
# wsize=8192 05min29
# wsize=16384 05min51
time dd if=/nfs/test/testfile of=/dev/null bs=16k # 32MB
# rsize=1024 10min29
# rsize=2048 7min11
# rsize=4096 5min10
# rsize=8192 read fault nach ~1min
# rsize=16384 manuell abgebrochen nach 20min
Ergibt für mich also rsize=4096,wsize=8192 und damit sieht die Performance schon ganz anders aus :)
-
Hast du diese Einstellung mal mit vielen kleinen Dateien lesen/schreiben verifiziert? Vor allem auch Dateien kleiner als 4 bzw. 8 k ?
-
Hast du diese Einstellung mal mit vielen kleinen Dateien lesen/schreiben verifiziert? Vor allem auch Dateien kleiner als 4 bzw. 8 k ?
...läuft noch :) Ich werde das auch noch ein-zwei Tage hin und her testen, bevor ich neuen Senf dazu abgebe.
-
Kleiner Nachtrag: Ich war mit der Übertragungsrate unzufrieden und habe mal ein bisschen an den mount-Einstellungen geschraubt. Vorlage dafür ist http://nfs.sourceforge.net/nfs-howto/ar01s05.html
Ergebnis ist, dass die in den vielen Dokus angegebene rsize/wsize -Größe von 1024 für den Popo ist. Zumindest bei mir; vielleicht ist das aber auch der Vergangenheit geschuldet, als man noch 10- oder gar schon 100MBit hatte. Heute dürfte ja 1000MBit das Mindeste sein, was man laufen hat.
Nun hat man leider an den wenigsten TOS-Rechnern 1 GBit/s, daher die Frage, ob deine Tests/Empfehlungen auch mit einem beteiligten TT/Falcon/Milan gelten?
-
Nun hat man leider an den wenigsten TOS-Rechnern 1 GBit/s, daher die Frage, ob deine Tests/Empfehlungen auch mit einem beteiligten TT/Falcon/Milan gelten?
Oh ja - nur damit wir uns richtig verstehen: Der Falcon, mit dem ich gerade mein LAN penetriere, ist quasi unverbastelt und hat ein schnödes altes EtherNec am ROM-Port, welches mit 10MBit an meinem 1000MBit-LAN hängt. Da will ich doch natürlich das Optimum für den Falcon herausholen und Faktor 2 ist schon mal nicht schlecht.
-
Klappte das bei dir mit der EtherNec direklt am Gigabit-Port des Switches? Bei mir nicht, ich musste einen 10/100 Switch dazwischen stecken. Mein Gigabit-Switch lässt sich nicht so weit herab...
-
Ja, es ist wie ich es in Erinnerung habe... Kobold kann alle Laufwerke bis Z: Es kann auf den MiNT-ext2-Laufwerken und auf dem ZIPLaufwerk sogar lange Dateinamen. Aber es sieht Laufwerk U: nicht, auch wenn man U: in Kobold als GEMDOS Laufwerk markiert. Und es kann nicht mit symbolischen Links umgehen, ein "ln -s u:/nfs k:/mnt/nfs" (k ist mein MiNT Systemlaufwerk, ext2) führt dazu, dass Kobold in k:/mnt folgendes anzeigt: "nfs <link>". Anklicken oder Doppelklick führt zu nichts. Im Desktop oder in der Shell kann ich aber da in nfs rein und sehe alles auf meinem Server.
-
Nutzt stattdessen KK Commander und ihr habt diese Probleme nicht mehr! ;D
https://ptonthat.fr/kk-commander/ (https://ptonthat.fr/kk-commander/)
Mit dem kann man auch auf "U" zugreifen und infolgedessauf NFS-Shares. 8)
-
Hier mal Beweisfotos. 8) Der KK Commander hat auch keine Schwierigkeiten bzw. Beschränkungen in Sachen EXT2-/FAT32-Volumes und man kann die Zeichensatzcodierung entsprechend einstellen, was auch nicht gerade unwichtig ist, wenn man z. B. auf ein HFS+-Volume kopiert, damit nicht Umlaute "kaputt" gehen.
Soll aber jeder nutzen, was sie/er will und für seine Zwecke am besten ist. Ich stehe mit Kobold eh ein wenig auf Kriegsfuss, weil u. a. kopieren/Backup auf ein NFS-Volume damit nicht wirklich geht. Mit dem KK Commander schon. 8)
-
Ich bevorzuge einen ´richtigen´ Desktop, zB, Thing oder Jinnee. Aber die Sache mit der Zeichensatzcodierung scheint ein Alleinstellungsmerkmal des KK-C. zu sein?
-
Wenn du Jinnie benutzt, sollte es eigentlich kein Problem sein. Da konnte man irgendwo einstellen, daß Kobold für bestimmte Laufwerke nicht benutzt wird.
-
Hast du diese Einstellung mal mit vielen kleinen Dateien lesen/schreiben verifiziert? Vor allem auch Dateien kleiner als 4 bzw. 8 k ?
Jetzt ja. Ergebnisse wie folgt. Das Test-Verzeichnis mit 100MB enthält viele viele kleine Dateien bis 4KB, viele bis 8KB und wenige mit >8KB.
time cp -a /nfs/pve1/test100mb/ /tmp/x/ #100MB
# rsize=1024,wsize=1024 56min13
# rsize=2048,wsize=2048 42min28
# rsize=4096,wsize=4096 35min28
# rsize=8192,wsize=8192 37min34
time cp -a /tmp/x/ /nfs/pve1/killme/ #100MB
# rsize=1024,wsize=1024 62min52
# rsize=2048,wsize=2048 53min30
# rsize=4096,wsize=4096 49min9
# rsize=8192,wsize=8192 49min5
Mit den Zeiten bei rsize/wsize=4096 kann man schon ganz gut arbeiten, aber so wirklich zufrieden bin ich immer noch nicht. Denn eigentlich sollten bei 10MBit ja circa 1MB durch die Leitung wuppen und davon bin ja noch weit entfernt.
Irgendwo hatte ich gelesen, dass man tunlichst versuchen solle, die ISA-Karte in einen ollen PC einzubauen, um ihr "einen IRQ zuweisen" (womit der dann überhaupt erst eingeschaltet sei und das beim Atari für einen Boost sorgen soll). Ich finde den Artikel/Link aber gerade nicht mehr...hat wer mir dazu etwas erhellendes zu sagen?
-
Klappte das bei dir mit der EtherNec direklt am Gigabit-Port des Switches? Bei mir nicht, ich musste einen 10/100 Switch dazwischen stecken. Mein Gigabit-Switch lässt sich nicht so weit herab...
Jein :) Der große GBit-Switch ist auf dem Dachboden verbaut, von dort aus quer durchs Haus bis zu kleineren GBit-Switches. Und ggf., wie im Falle der Ataris, dann nochmals an ganz kleine und billige GBit-Switches. Die aber hatten kein Problem mit der 10MBit-Anbindung.
Und ja, ich weiß, schön ist diese Lösung nicht, aber sie funktioniert seit einigen Jahren problemlos mit 100/1000MBit-Verbindungen und ich habe auch überall damit die maximal mögliche Geschwindigkeit.
-
wirklich zufrieden bin ich immer noch nicht. Denn eigentlich sollten bei 10MBit ja circa 1MB durch die Leitung wuppen und davon bin ja noch weit entfernt.
Wieviel Durchsatz zeigt dir iperf an, erstmal egal ob Version 2 oder 3? Damit kannst du schonmal die "wire speed" gut annähern.
-
Wieviel Durchsatz zeigt dir iperf an, erstmal egal ob Version 2 oder 3? Damit kannst du schonmal die "wire speed" gut annähern.
Ausgezeichnete Idee! Das ist mal wieder so naheliegend, dass man selber nicht darauf kommt :)
192.168.2.1 Debian-Server
192.168.2.79 Falcon030
# iperf -c 192.168.2.79 -u -b 10m
------------------------------------------------------------
Client connecting to 192.168.2.79, UDP port 5001
Sending 1470 byte datagrams, IPG target: 1176.00 us (kalman adjust)
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.2.1 port 52291 connected with 192.168.2.79 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 11.9 MBytes 10.0 Mbits/sec
[ 3] Sent 8505 datagrams
[ 3] Server Report:
[ 3] 0.0- 7.9 sec 125 KBytes 129 Kbits/sec 65.784 ms 8419/ 8506 (99%)