Forum: PC Hard- und Software (NFS) Netzwerk-Shares unter Linux


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Daniel F. (df311)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Noch einer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Schon mal die Mount-Optionen "bg,soft,timeo=N" versucht?

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von jz23 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Warum nutzt du nicht einfach SMB weiter?

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
jz23 schrieb:
> Warum nutzt du nicht einfach SMB weiter?

Machst du das so? Das grundsätzliche Problem bleibt damit aber bestehen, 
oder nicht?

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
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
von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Meine Erfolgsquote bei umount -f ist durchwachsen.

kann ich bestätigen.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
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.

von c.m. (Gast)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
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.

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
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" ;)

von out of time (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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."


---

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Probier auf der Server-Seite die Option "async".

von Kommandozeile vor dem Frühstück für Alle! (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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?

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Michael R. (fisa)


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
Was ist das denn für ein NAS? Die meisten dieser Standalone-Geräte kamen 
mir immer etwas lahm vor...

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
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).

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Kommandozeile vor dem Frühstück für Alle! (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Egon N. (egon2321)


Bewertung
0 lesenswert
nicht lesenswert
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. ;)

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von out of time (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
256K und 512K. Also weit jenseits der 32K, die ich im NFS verwende.
Und nun?

: Bearbeitet durch User
von out of time (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von out of time (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wen interessiert hier die Farbe?

WD malt die je nach Haupteinsatzzweck verschiedenfarbig an. Die roten 
sind für NAS/Server.

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ach du willst es genau wissen? Allzuviele dürfte es nicht geben, aber 
konkret habe ich die WD20EFRX und die WD30EFRX.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Egon N. (egon2321)


Bewertung
0 lesenswert
nicht lesenswert
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
von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/...

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Wenn eine Minute noch zu lange ist,

Mit fcron gehts auch häufiger als minütlich.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.