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.
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.
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.
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.
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.
Vielleicht habe ich da auch nur nen groben Schnitzer drin, aber ich habe
auch schon verschiedenes versucht und damit die besten schlechten
Erfahrungen gemacht.
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
> 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.
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 :-)
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
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--progresstestfile/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
ddif=testfileof=/mnt/test/testfilebs=
2
3
bs|Zeit,Geschw.
4
---------------------------
5
64k|44,3258s,84,8MB/s
6
256k|44,2781s,84,9MB/s
7
512k|47,0954s,79,8MB/s
8
1M|53,1948s,70,7MB/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.
> 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.
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.
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.
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:
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.
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.
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
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.
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?
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?
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.
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/...
Thread beobachten
Seitenaufteilung abschalten