Ich bin vor etwa einem Jahr von Windows 7 auf Linux umgestiegen (via kubuntu und openSUSE auf Arch, immer mit KDE). Unter Windows hatte ich meine SMB-Shares vom Synology-NAS als Netzlaufwerk eingerichtet und das hat gut funktioniert, auch wenn die Shares mal nicht verfügbar waren (Notebook). Auch das NAS lief/läuft nicht 24/7, sondern nur ein paar Stunden am Tag. Für Linux habe ich die Shares dann auf NFS umgestellt und per autofs automatisch un-/mounten lassen. Dabei kam es immer wieder vor, dass z.B. der Dolphin Filemanager eingefroren ist oder recht lange brauchte um zu starten. Ich habe nie wirklich herausgefunden warum das so war. Kürzlich habe ich mein Synology-NAS ausgemustert und einen PC mit OMV selbst aufgesetzt. Die Gelegenheit habe ich genutzt um von autofs auf systemd-Automounts zu wechseln, da ich dachte meine Probleme von oben seien damit vielleicht gelöst. Pustekuchen... Vorhin wollte ich ich bspw. mit dem Firefox eine Datei herunterladen und laut Dolphin waren alle meine Shares gemountet, obwohl der OMV-PC aus war. Firefox hat dann wohl versucht auf die Shares zuzugreifen (warum auch immer), obwohl ein völlig anderes Zielverzeichnis gewählt war und hing dann natürlich bis zu irgendeinem Timeout. Im Netz findet man fast nur Anleitungen, wie man die Sache einrichtet, aber wenig bis nichts dazu ob das dann auch wirklich im Alltag nutzbar ist. Also: wie handhabt man NFS-Shares (evtl. auch CIFS), die nicht ständig verfügbar sind am besten unter Linux?
für nicht dauernd verfügbare shares würde ich den automount weglassen und einfach bei bedarf händisch mounten. mach ich im büro mit einem langsamen, zum glück selten benötigten mount auch so.
NFS ist für Server, die immer an sind und nicht so Jojo-Server ala Windows ;) Deswegen sind die Default-Timeouts auf Client-Seite auch eine halbe Ewigkeit. Autofs/automount ist keine Lösung dagegen, weil das eben nicht vorher auf Verfügbarkeit testet, sondern beim ersten Zugriff (da reicht schon ein neugieriger Dir-Status im Open-Dialog) mounten will und dann hängt. Du könntest die Mountoptionen auf soft-mount und niedrige Timeouts/Retransmissions setzen. Aber etwas klemmen wird es immer und an sich ist "soft" schon gefährlich, weil auch im normalen Betrieb Daten verloren gehen könnten. Daher wird im Allgemeinen davon abgeraten. Oder man frickelt etwas und checkt in einem Cronjob minütlich, ob die IP des Servers pingt und ändert damit die Automount-Config passend.
Wenn du mich fragst, wie ich das handhabe... Ich mounte die Netzwerklaufwerke nicht mehr. Arbeite mit der lokalen Platte und benutze zum Kopieren auf die Netzwerklaufwerke den Mechanismus aus dem Dateimanager. Verhakt sich auch ab und zu mal, aber Dateimanager neu starten genügt. Gibt auch Editoren, die mit diesen "Dateimanager-Mounts" arbeiten. Keine gute Idee. Nachdem es 2 oder 3 mal beim Abspeichern hakte, benutze ich das auch nicht mehr.
Georg A. schrieb: > Oder man frickelt etwas und checkt in einem Cronjob minütlich, ob die IP > des Servers pingt und ändert damit die Automount-Config passend. Ich kann dir nicht folgen auf was du raus willst. In welche Richtung hattest du gedacht? A. K. schrieb: > Schon mal die Mount-Optionen "bg,soft,timeo=N" versucht? Ja, leider ohne Erfolg.
Mounte nichts, was nicht wirklich zuverlässig die ganze Zeit erreichbar ist. Egal welches Protokoll. Ansonsten hast Du so gut wie verloren und das ganze System klemmt hinten und vorne. Ist leider so. Unter KDE kannst Du kio nehmen um das Problem zu umgehen. Die Daten werden damit erst komplett ins lokale tmp kopiert, dort dann geöffnet und bearbeitet, und hinterher wieder hochkopiert. Funktioniert ganz gut für einzelne Dateien, ist aber für größere Mengen unpraktisch. Und geht natürlich nicht von der Kommandozeile aus, sondern nur aus KDE-Programmen raus.
Gibts in Linux ein ungefähres Äquivalent zu den von Notebooks bekannten Offline-Files in Windows? Also indem man auf einer lokalen Kopie automatisch synchronisierter Daten arbeitet, ohne viel davon zu merken.
:
Bearbeitet durch User
jz23 schrieb: > Warum nutzt du nicht einfach SMB weiter? Machst du das so? Das grundsätzliche Problem bleibt damit aber bestehen, oder nicht?
A. K. schrieb: > Gibts in Linux ein ungefähres Äquivalent zu den von Notebooks bekannten > Offline-Files in Windows? Also indem man auf einer lokalen Kopie > automatisch synchronisierter Daten arbeitet, ohne viel davon zu merken. Es gibt auch Netzwerk-Filesysteme, die die Daten lokal cachen und dann automatisch synchronisieren, oder z.B. auch sowas wie tsumufs, das auch auf nfs aufsetzen kann. Hab selbst aber noch nie eins ausprobiert. Gerd E. schrieb: > Mounte nichts, was nicht wirklich zuverlässig die ganze Zeit erreichbar > ist. Egal welches Protokoll. Ansonsten hast Du so gut wie verloren und > das ganze System klemmt hinten und vorne. Ist leider so. Du kannst immer noch mit umount -f unmounten, das sollte das System wieder gängig machen.
:
Bearbeitet durch User
Rolf M. schrieb: > Du kannst immer noch mit umount -f unmounten, das sollte das System > wieder gängig machen. Meine Erfolgsquote bei umount -f ist durchwachsen.
Micha schrieb: > Also: wie handhabt man NFS-Shares (evtl. auch CIFS), die nicht ständig > verfügbar sind am besten unter Linux? Ich verwende autofs, um meine NFS-Shares zu mounten. Ich würde auf jeden Fall die mount-Option "soft" empfehlen, eventuell noch "timeo=N" (man 5 nfs). Außerdem sollte man auch die Timeouts für autofs kontrollieren (für Debian/Ubuntu in /etc/default/autofs). Autofs sollte ein ungenutztes Filesystem möglichst zeitnah aushängen. Denn zu Problemen kommt es in der Regel dann, wenn der NFS-Server verschwindet, während ein Client noch ein Share gemounted hat. Je kürzer man diese Zeitspanne macht, desto weniger Probleme wird man bekommen. Wenn man das NAS allerdings ausschaltet, während der Client gerade aktiv Daten hin- und her schiebt, dann wird man so oder so keine Freude haben. Das ist dann aber eigene Dummheit.
:
Bearbeitet durch User
A. K. schrieb: > Gibts in Linux ein ungefähres Äquivalent zu den von Notebooks bekannten > Offline-Files in Windows? Also indem man auf einer lokalen Kopie > automatisch synchronisierter Daten arbeitet, ohne viel davon zu merken. Bestimmte Unterverzeichnisse meines Homedirs synce ich beim Login per rsync auf eine lokale SSD und schiebe sie beim Logout wieder auf den NFS-Server. Ziel ist bei mir primär Performance, aber könnte man natürlich auch gegen Ausfall des Servers nutzen. Da würde man dann den mount nur während des Syncs machen oder direkt rsync über ssh ohne mount nutzen.
Angehängte Dateien:
-
sftp-thunar.png
33 KB
die probleme mit hängendem NFS kenne ich schon seit ich mit linux/solaris arbeite. manchmal haben harte locks sogar ihre vorteile, in 99% aller fälle aber nicht. smb hat halt das problem mit den dateiberechtigungen, außerdem mag ich das protokoll nicht, weil die samba entwickler das geschnuddel von microsoft nachprogrammieren mussten - ist mir zu undurchsichtig. hat aber auch seine daseinsberechtigung, vor allem wenn windows rechner auch aus shares zugreifen sollen. ich benutze seit ein paar jahren im heimnetz eine mischung aus sftp (einzelne dateien über dateimanager kopieren), iSCSI (blockdevice für backups) und unison über ssh (ordnersynchronisation von verschiedenen rechnern). damit habe ich bisher die wenigsten probleme.
Micha schrieb: > Ich kann dir nicht folgen auf was du raus willst. In welche Richtung > hattest du gedacht? Du hast ein fstab-Setup mit automounts, eins ohne. Je nach ping-Ergebnis wird das nach /etc/fstab verlinkt und der systemd getriggert, dass er das neu einliest. Naja, nicht schön, aber ich sagte ja "gefrickelt" ;)
Micha schrieb: > > A. K. schrieb: >> Schon mal die Mount-Optionen "bg,soft,timeo=N" versucht? > > Ja, leider ohne Erfolg. timeouts setzen? https://unix.stackexchange.com/a/31981 "using only bg,intr,soft still leaves a hang of 120 seconds in Fedora 20. But adding timeo=5,retrans=5,actimeo=10,retry=5 makes it nice and quick." ---
Georg A. schrieb: > Micha schrieb: >> Ich kann dir nicht folgen auf was du raus willst. In welche Richtung >> hattest du gedacht? > > Du hast ein fstab-Setup mit automounts, eins ohne. Je nach ping-Ergebnis > wird das nach /etc/fstab verlinkt und der systemd getriggert, dass er > das neu einliest. Naja, nicht schön, aber ich sagte ja "gefrickelt" ;) OK, verstehe. Lasse ich mir mal durch den Kopf gehen. out of time schrieb: > timeouts setzen? > > https://unix.stackexchange.com/a/31981 > > "using only bg,intr,soft still leaves a hang of 120 seconds in Fedora > 20. But adding timeo=5,retrans=5,actimeo=10,retry=5 makes it nice and > quick." actimeo und retrans hatte ich noch nie probiert. Werde ich mal testen. Da jetzt schon ein paar Hinweise auf die verwendeten Optionen kamen: für autofs hatte ich bspw.
1 | -fstype=nfs,noatime,nodiratime,soft,retry=0,timeo=10,bg,nofail,intr,users,suid,_netdev,proto=tcp,ro |
und für systemd
1 | ro,bg,intr,soft,users,noauto,_netdev,proto=tcp,retry=3,timeo=10,x-systemd.automount,x-systemd.device-timeout=10,x-systemd.idle-timeout=1min |
Vielleicht habe ich da auch nur nen groben Schnitzer drin, aber ich habe auch schon verschiedenes versucht und damit die besten schlechten Erfahrungen gemacht.
Irgendwie kapier ich es nicht. Jetzt habe ich mal komplett auf Automounts verzichtet und meine Freigaben in der fstab mit
1 | nfs bg,intr,hard,users,noauto,nodiratime,nofail,_netdev,proto=tcp,actimeo=10,timeo=5,retrans=5,retry=5 |
angelegt. In Dolphin kann ich dann links unten unter 'Geräte' manuell mounten und unmounten. Von der Handhabung her wäre das OK. Wenn ich nun eine Datei auf den Server kopiere, zeigt mir Plasma im Tray eine Geschwindigkeit von ca. 27 MiB/s an. Wenn ich dieselbe Datei mit rsync auf dieselbe Freigabe kopiere erreicht er 108,970,291.13 bytes/sec. Wie kann das passieren? 'mountstats' zeigt mir
1 | NFS mount options: rw,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,acregmin=10,acregmax=10,acdirmin=10,acdirmax=10,hard,proto=tcp,timeo=5,retrans=5,sec=sys,clientaddr=192.168.192.20,local_lock=none |
Beitrag #5287167 wurde vom Autor gelöscht.
> Wenn ich nun eine Datei auf den Server kopiere, zeigt mir Plasma im Tray > eine Geschwindigkeit von ca. 27 MiB/s an. Wenn ich dieselbe Datei mit > rsync auf dieselbe Freigabe kopiere erreicht er 108,970,291.13 > bytes/sec. > > Wie kann das passieren? rsync lügt manchmal: bei unstetem Durchsatz. S. auch c't 2018-03. Oder hat es tatsächlich nur 1/4 solange gedauert?
Ich habe mal mit den verschiedenen Optionen rumgespielt und habe nichts gefunden, mit dem ich bei einem ausreichend schnellen mit btrfs betriebenen Volume als Ziel auf 27 MB/s runter käme. Sync,async,udp,tcp,32k/1M,... ergibt Unterschiede, aber unter 50 MB/s kam ich nicht einmal bei einem ext4 Volume auf einer alten 5400er Disk, die auch auf dem Server selbst nur um die 100 MB/s schafft. Der Server ist ein HP Microserver N36L mit Debian 8, der Client ein AMD Sempron 140 mit einem Derivat von Ubuntu 11. Also beides wahrlich keine Rennpferde. Womit hast du bei NFS kopiert? Ich teste das gerne mit sowas wie dd if=/dev/zero of=/mnt/test bs=64k um den Einfluss der Grösse der Requests prüfen zu können.
:
Bearbeitet durch User
A. K. schrieb: > Rolf M. schrieb: >> Du kannst immer noch mit umount -f unmounten, das sollte das System >> wieder gängig machen. > > Meine Erfolgsquote bei umount -f ist durchwachsen. ich nehm meistens umount -fl (lazy) speziell wenn ich wieder mal die VM runtergefahren hab, und vorher den umount im Host vergessen habe :-)
Was ist das denn für ein NAS? Die meisten dieser Standalone-Geräte kamen mir immer etwas lahm vor...
A. K. schrieb: > Probier auf der Server-Seite die Option "async". War beim Test bereits aktiv. Für diese Freigabe lauten die Optionen in der /etc/exports
1 | fsid=7,rw,async,no_subtree_check,all_squash,anonuid=1028,anongid=100 |
Kommandozeile vor dem Frühstück für Alle! schrieb: > rsync lügt manchmal: bei unstetem Durchsatz. S. auch c't 2018-03. Oder > hat es tatsächlich nur 1/4 solange gedauert? Berechtigter Einwand. Mit rsync ~30s, mit Dolphin ~42s. Die Geschwindigkeiten liegen also näher beisammen als zunächst angenommen. A. K. schrieb: > Womit hast du bei NFS kopiert?
1 | rsync -av --progress testfile /mnt/test/ |
wobei testfile etwa 3.5GiB groß ist. A. K. schrieb: > Ich teste das gerne mit sowas wie > dd if=/dev/zero of=/mnt/test bs=64k > um den Einfluss der Grösse der Requests prüfen zu können. Habe ich eben mal gemacht:
1 | dd if=testfile of=/mnt/test/testfile bs= |
2 | |
3 | bs | Zeit , Geschw. |
4 | ---------------------------
|
5 | 64k | 44,3258 s, 84,8 MB/s |
6 | 256k | 44,2781 s, 84,9 MB/s |
7 | 512k | 47,0954 s, 79,8 MB/s |
8 | 1M | 53,1948 s, 70,7 MB/s |
Georg A. schrieb: > Was ist das denn für ein NAS? Die meisten dieser Standalone-Geräte kamen > mir immer etwas lahm vor... Ein Eigenbau mit einem ASRock J4205-ITX, 8GB RAM, Debian 9.3 mit Kernel 4.14 und 2 WD-Red als Datengrab.
Micha schrieb: > Ein Eigenbau mit einem ASRock J4205-ITX, 8GB RAM, Debian 9.3 mit Kernel > 4.14 und 2 WD-Red als Datengrab. Ah, hatte das Wörtchen "ausgemustert" im ersten Post übersehen... BTW: In den neueren Kernels wurde die Performance von SSDs verbessert. Leider auf Kosten von normalen Platten. Und zwar so extrem, dass zB. mit einem SW-RAID6 die VMs dreimal so lange zum booten brauchen. Schau mal bei dir unter /sys/block/sd*/queue/max_sectors_kb nach. "Neuerdings" steht da 1280 drin, normale Platten laufen mit 256 deutlich responsiver... Das fällt insbesonderen bei vielen kleinen IOs auf. Zur Performancesteigerung für den Durchsatz auf Serverseite könnte man den Read-Ahead grösser machen (zB. blockdev --setra 1024 /dev/sd* bzw. noch etwas grösser bei RAID-Devices).
Micha schrieb: > dd if=testfile of=/mnt/test/testfile bs= Es ist von Vorteil, Performancefragen auch abschnittsweise zu testen, nicht nur alles zusammen. Mit if=/dev/zero nimmst du die Disk-I/O des lokalen Systems aus der Rechnung, um sicher zu sein, nur Netz, Protokoll und Server zu testen. Je nach Server und Netz kann auch die Länge des Transfers eine Rolle spielen. Bleibt man deutlich unter der RAM-Kapazität des Servers, können Cache-Effekte die Auswirkungen der Disk-I/O des Servers verbergen (nicht wenn "sync") und man misst dann möglicherweise nur Netz und Protokoll.
:
Bearbeitet durch User
> Womit hast du bei NFS kopiert? Ich teste das gerne mit sowas wie > dd if=/dev/zero of=/mnt/test bs=64k > um den Einfluss der Grösse der Requests prüfen zu können. Ahja... zero - da freuen sich schlaue cacheing Subsysteme und fs mit sparse file handling Ich nehme dafür lieber eine Abbilddatei einer CD oder DVD (Installationsmedium oder Heftarchiv). Immer schön eine /statistisch relevante Anzahl/ Male wiederholen um Verzerrungen der Ergebnisse durch (noch nicht greifende) cacheing Effekte zu vermeiden.
Micha schrieb: > rsync -av --progress testfile /mnt/test/ Mit rsync 14s, mit cp 12s bei gleichem File. Wobei rsync den armen Sempron ziemlich an die Kante kriegt, 90% Last gegenüber 40% bei cp.
Ich habe o.g. Test um CIFS erweitert:
1 | dd if=testfile of=/mnt/test/testfile bs= |
2 | |
3 | bs | Zeit , Geschw. | Prot. |
4 | -----------------------------------
|
5 | 64k | 44,3258 s, 84,8 MB/s | NFS4 |
6 | 256k | 44,2781 s, 84,9 MB/s | NFS4 |
7 | 512k | 47,0954 s, 79,8 MB/s | NFS4 |
8 | 1M | 53,1948 s, 70,7 MB/s | NFS4 |
9 | -----------------------------------
|
10 | 512k | 34,0047 s, 111 MB/s | CIFS |
11 | 1M | 33,1692 s, 113 MB/s | CIFS |
A. K. schrieb: > Mit if=/dev/zero nimmst du die Disk-I/O des > lokalen Systems aus der Rechnung, um sicher zu sein, nur Netz, Protokoll > und Server zu testen. Lokal auf dem Client habe ich eine SSD (Samsung 750 256GB), lesend müsste die locker mithalten können. Kommandozeile vor dem Frühstück für Alle! schrieb: > Ich nehme dafür lieber eine Abbilddatei einer CD oder DVD > (Installationsmedium oder Heftarchiv). Mein 'testfile' ist ein MPEG2-kodierter Film.
Kommandozeile vor dem Frühstück für Alle! schrieb: > Ahja... zero - da freuen sich schlaue cacheing Subsysteme und fs mit > /sparse file handling/ Und? Wie vorhin schon geschrieben wäre mir das sogar recht. NFS selbst macht zumindest bei mir keine derartige Optimierung. Je weniger Einfluss also der FS/Storage-Layer der NAS nimmt, desto mehr erfahre ich gezielt über Netz/NFS. Klassische sparse files enthalten nicht allozierte Blöcke, weil sie nie geschrieben wurden. Gibt es Filesysteme, die Blöcke auf Nullen testen und deshalb nicht schreiben? Das sollte man auf dem Server per dd if=/dev/zero of=testfile mühelos feststellen können. Weil dann mindestens ein Core auf Max laufen und ein Durchsatz jenseits von gut und böse rauskommen wird. Ist hier nicht der Fall, ich kriege das, was die Disk-I/O hergibt.
A. K. schrieb: > Mit rsync 14s, mit cp 12s bei gleichem File.
1 | Dolphin CIFS: 34s |
2 | cp -a : 38s |
3 | rsync : 43s |
4 | Dolphin NFS : 47s |
Micha schrieb: > Mein 'testfile' ist ein MPEG2-kodierter Film. Mit so einem Files sind es 92 MB/s gegenüber 95 MB/s bei /dev/zero. Eine SSD mit 255 MB/s (SATA2-Anschluss) bremst also immer noch leicht ab.
Micha schrieb: > Dolphin CIFS: 34s > cp -a : 38s > rsync : 43s > Dolphin NFS : 47s rsync und cp waren hier auch via NFS. Ist CIFS performanter als NFS? Im Netz liest man egtl. immer das Gegenteil. Den Test mit /dev/zero führe ich später noch durch.
Micha schrieb: > Ist CIFS performanter als NFS? Im Netz liest man egtl. immer das > Gegenteil. Das klassische SMB/CIFS war auch in Windows erheblich langsamer als das Netz. Mit SMB 2.0 hat sich das in Windows geändert, da gehts bei Gbit-Netzwerk ans Limit. Sowohl der vorige Client also auch ein neuerer und fixerer Client (jedoch eine VM) lesen NFS mit 117 MB/s. Der Sempron schreibt mit 95 MB/s, der andere mit 103 MB/s. In Linux komme ich per CIFS-Mount nicht annähernd an diese Werte heran. Windows liest jedoch praktisch am Limit vom Netz.
:
Bearbeitet durch User
A. K. schrieb: > dd if=/dev/zero of=/mnt/test bs=64k Ergibt sich mit 64k ein aussagekräftiges Ergebnis oder braucht es dafür mehr?
Micha schrieb: > Ergibt sich mit 64k ein aussagekräftiges Ergebnis oder braucht es dafür > mehr? Vergiss es. Eben hab ich es kapiert und mal auf dem Server getestet:
1 | $ sudo dd if=/dev/zero of=/srv/dev-disk-by-label-vol1/temp/zero.txt bs=64k |
2 | 6741426176 Bytes (6,7 GB, 6,3 GiB) kopiert, 61,29 s, 110 MB/s |
A. K. schrieb: > In Linux komme ich per CIFS-Mount nicht annähernd an diese Werte heran. Eben das wundert mich ja auch gerade. OK, lesen habe ich nicht probiert, aber dass via CIFS schneller geschrieben wird als via NFS überrascht mich.
Via NFS vom Client auf den Server:
1 | $ dd if=/dev/zero of=/mnt/server/temp/zero.txt bs=64k |
2 | 5047910400 bytes (5,0 GB, 4,7 GiB) copied, 62,0791 s, 81,3 MB/s |
und via CIFS auf den Server:
1 | $ dd if=/dev/zero of=/mnt/test/zero2.txt bs=64k |
2 | 6040453120 bytes (6,0 GB, 5,6 GiB) copied, 62,9228 s, 96,0 MB/s |
Micha schrieb: > Ist CIFS performanter als NFS? Im Netz liest man egtl. immer das Man müsste jetzt wissen wie die Config aussieht. In der Regel ist UDP nämlich deaktiviert, das muss man erst mal aktivieren damit NFS schnell wird. ;)
Egon N. schrieb: > Man müsste jetzt wissen wie die Config aussieht. > > In der Regel ist UDP nämlich deaktiviert, das muss man erst mal > aktivieren damit NFS schnell wird. ;) Micha schrieb: > 'mountstats' zeigt mirNFS mount options: > rw,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,acregmin=10,acregmax= 10,acdirmin=10,acdirmax=10,hard,proto=tcp,timeo=5,retrans=5,sec=sys,clie ntaddr=192.168.192.20,local_lock=none
Micha schrieb: > Ergibt sich mit 64k ein aussagekräftiges Ergebnis oder braucht es dafür > mehr? Siehst du doch selbst. Mehr bringt nichts. Das gilt meinen Tests zufolge auch für rsize/wsize in fstab.
Egon N. schrieb: > In der Regel ist UDP nämlich deaktiviert, das muss man erst mal > aktivieren damit NFS schnell wird. ;) Probiert es aus. Ich habe mit TCP eher bessere Erfahrungen gemacht. UDP ist das Original, TCP kam später hinzu.
Micha schrieb: > Vergiss es. Eben hab ich es kapiert und mal auf dem Server getestet: Lokal auf dem Server maximal 110 MB/s? Nicht umwerfend. Bissel Luft gegenüber Gigabit-Ethernet sollte schon sein. Was für Disks, Filesystem, RAID etc? Meine ST4000DM00 liegen im Test bei 160-170 MB/s, laut Datasheet im Mittel 146 MB/s. 2 Stück gespiegelt per btrfs.
:
Bearbeitet durch User
A. K. schrieb: > Micha schrieb: >> Ergibt sich mit 64k ein aussagekräftiges Ergebnis oder braucht es dafür >> mehr? > > Siehst du doch selbst. Mehr bringt nichts. Das gilt meinen Tests zufolge > auch für rsize/wsize in fstab. Guckt doch erstmal was der Server verwendet?! cat /proc/fs/nfsd/max_block_size
256K und 512K. Also weit jenseits der 32K, die ich im NFS verwende. Und nun?
:
Bearbeitet durch User
A. K. schrieb: > 245K und 512K. Also weit jenseits der 32K, die ich im NFS verwende. Und > nun? Weisst du das du drunter liegst, woher soll jmd. anderes das wissen :) Was gibts evtl. noch zu checken ? network packet size local page size irgendwo gabs mal ein Optimizing NFS Performance howto. Das ist zwar alt gibt aber evtl. weitere Hinweise. bye.
out of time schrieb: > network packet size Wenn ich mal davon ausgehen darf, dass wir im geswitchten LAN bleiben, ist das dank Einheits-Ethernet heute kein Thema mehr. Die Zeiten von jumbo frames sind vorbei. > local page size Sachte. Wir sind in 2018 bei 1 Gbit-Ethernet und RAM-Anbindungen mit 1-2stelligen GByte/s. Nicht bei 10 Gbit auf einem 486. ;-) Michas NAS hat einen Quadcore Apollo Lake drin. Das ist zwar "nur" die aktuelle Atom-Klasse, aber damit immer noch locker gut genug. Meine AMDs haben lediglich den unerwarteten Vorteil, dass ihnen Meltdown keine Angst einjagt.
:
Bearbeitet durch User
A. K. schrieb: > 256K und 512K. Also weit jenseits der 32K, die ich im NFS verwende. > Und nun? was passiert wenn man 4k fuer die 'csa_back_chan_attrs' draufschlaegt? Also eg. der will ja 131072 / 128k 'kriegt aber 64+4k Brocken'. "Note that rsize and wsize are requests, the client and server must negotiate a mutually supported set of parameters." https://cromwell-intl.com/open-source/performance-tuning/nfs.html ---- gibt nicht viel gescheites ueber 4.x im Netz
A. K. schrieb: > Was für Disks, Filesystem, RAID etc? 1x WD Red 2TB und 1x WD Red 3TB, Ext4, JBOD. out of time schrieb: > Guckt doch erstmal was der Server verwendet?! > > cat /proc/fs/nfsd/max_block_size 1048576 Egon N. schrieb: > In der Regel ist UDP nämlich deaktiviert, das muss man erst mal > aktivieren damit NFS schnell wird. ;) Meinst du das allein sorgt für die "Langsamkeit" von NFS? Bzgl. der ursprünglichen Frage versuche ich mein Glück jetzt erst mal ganz ohne Automounts mit festen Einträgen in der fstab. Damit lässt es sich recht komfortabel aus Dolphin heraus un-/mounten, soweit ich das bisher sagen kann. Ggf. frickel ich mir in Anlehnung an Beitrag "Re: (NFS) Netzwerk-Shares unter Linux" noch einen cron-Job zusammen, je nachdem wo ich noch Potential sehe. Dafür muss ich jetzt aber erst mal sehen wie sich o.g. bewährt. Was die Geschwindigkeit angeht verstehe ich noch immer nicht warum CIFS entgegen aller Erwartungen schneller zu sein scheint als NFS. Evtl. stelle ich daher auf CIFS um, obwohl ich nur Linux-Clients im Netz habe. Mal sehen... out of time schrieb: > gibt nicht viel gescheites ueber 4.x im Netz Soll ich noch was nachsehen oder probieren? Deinen Link führe ich mir morgen mal zu Gemüte...
Micha schrieb: > 1x WD Red 2TB und 1x WD Red 3TB, Ext4, JBOD. Wen interessiert hier die Farbe? Oder gibts da wirklich nur eine einzige rote Disk bei gegebener Kapazität?
:
Bearbeitet durch User
A. K. schrieb: > Wen interessiert hier die Farbe? WD malt die je nach Haupteinsatzzweck verschiedenfarbig an. Die roten sind für NAS/Server.
Ach du willst es genau wissen? Allzuviele dürfte es nicht geben, aber konkret habe ich die WD20EFRX und die WD30EFRX.
Bei der WD20EFRX stehen max 147 MB/s drin. Die 110 passen, wenn die Spuren eher innen als aussen liegen. Wundert mich nicht, wenn in der Praxis via Netz und Protokoll das Ethernet dann nicht am Limit klebt. Verwendet man 5400er nicht eher dann, wenn man es nicht eilig hat?
:
Bearbeitet durch User
A. K. schrieb: > Verwendet man 5400er nicht eher dann, wenn man es nicht eilig hat? Im Mittel habe ich es auch nicht eilig. Ich hatte mich erst über die niedrige, in KDE angezeigte Rate gewundert. Es hat sich aber im Verlauf des Threads herausgestellt, dass die Übertragung zwar etwas länger dauert als mit cp, aber sich in etwa im Rahmen des Machbaren bewegt. Danach hatte ich mich noch über den Unterschied CIFS <-> NFS gewundert. Was ich nach wie vor tue...
A. K. schrieb: > Egon N. schrieb: >> In der Regel ist UDP nämlich deaktiviert, das muss man erst mal >> aktivieren damit NFS schnell wird. ;) > > Probiert es aus. Ich habe mit TCP eher bessere Erfahrungen gemacht. UDP > ist das Original, TCP kam später hinzu. Micha schrieb: > Meinst du das allein sorgt für die "Langsamkeit" von NFS? UDP bringt insbesondere etwas wenn ein Interface am Rande seiner Kapazität genutzt wird, z.B. diese Android TV Boxen haben Probleme mit 4k Bildmaterial vom NAS wenn man nicht auf UDP umstellt weil die ACK bei TCP sonst deren Fast Ethernet Anbindung überfordern. Wobei ich persönlich auch noch nach einer Lösung mit meinem Laptop suche, entnehme ich den aus der Dockingstation und habe noch ein Mount von einer Samba Share offen ist Dolphin usw. träge, da darf ich dann erst mal mit einem umount -lf die Share unmounten damit das System wieder läuft.
:
Bearbeitet durch User
Egon N. schrieb: > Wobei ich persönlich auch noch nach einer Lösung mit meinem Laptop > suche, entnehme ich den aus der Dockingstation und habe noch ein Mount > von einer Samba Share offen ist Dolphin usw. träge, da darf ich dann > erst mal mit einem umount -lf die Share unmounten damit das System > wieder läuft. Angeregt durch den Beitrag von Georg A. überlege ich mir auch das über einen cron-Job zu erledigen, der jede Minute ausgeführt wird und überprüft ob der Server noch erreichbar ist. Wenn eine Minute noch zu lange ist, lässt es sich durch sleeps auch noch halbieren/dritteln/vierteln/...
Micha schrieb: > Wenn eine Minute noch zu lange ist, Mit fcron gehts auch häufiger als minütlich.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.