Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.protocols.misc > #367

Re: Netzwerkdateisystem, was Standby aushält

Show all headers | View raw

Marco Moock wrote: 

> Ich suche aktuell ein Netzwerkdateisystem für einen Mount, was aushält,
> wenn ein Client in Standby geht --> der muss das erkennen und darf dann
> nicht abstürzen oder nen Timeout produzieren, sondern muss nach dem
> Aufwecken die Verbindung wieder aufbauen. Was wäre da geeignet?
>
> NFS finde ich abschreckend, weil das wohl nicht auf User-Ebene geht.
> SMB klingt da besser, weil die Dateimanager das einbinden können.
>
> Was nutzt ihr da so?

Entschuldig(t) die späte Antwort. War wieder ein hektisches Jahr,
hatte direkt keine Zeit für eine ausführliche Antwort, und M. hatte
die Kurzantwort "NFS" ja schon verworfen. Dann hab ich's aus den
Augen verloren, uns sonst hat ja auch niemand geantwortet...

Tatsaechlich durchaus NFS.

a) Nichts im NFS- und RPC-Protokill spricht gegen Implementierung auf
Userebene. Ich weiss von einer NFS-Server-Implementierung auf
Userebene. (Hab aber vergessen, wie sie heisst; ich brauchte vor
Jahrzehnten einen Zweitserver auf dem selben Exportfilesystem mit
anderer Konfiguration fuer einen test.)

b) Auf den offline erhaltenen Einwand, dass man grundsätzlich jedem
beteiligten Rechner vertraue: Bis zu einem gewissen Grad.
Voraussetzung ist halbwegs koordinierte Systemadministration.  Sehr
früh gabs schon die serverseitige Konfigurationsoption, root nach
nobody zu mappen (genauer: der Default; die option war, es nicht
zu tun).  In moderneren Zeiten (aber auch schon lange) gibt's
kerberized NFS. Dann muss man Kerberos moegen, aber homes koennen
einzeln und vor den Blicken/Zugriffen anderer User geschuetzt 
gemountet werden. Auch hier ist die Voraussetzung halbwegs koordinierte
Administration.

c) NFS wurde designt, um serverreboot zu ueberleben. Du brauchst
einen hard mount (sonst schlaegt der timeout ggfls zu), dann wartet
der betroffene clientprozess brav darauf, dass der Server wieder hoch
kommt und laueft dann ungeruehrt weiter. Ich benutze in solchen
fallen "hard,intr", damit der haengende Userprozess abgebrochen
werden kann.

Ok, es das Weiterlaufen nach Serverreboot funktioniert mindestens
bei traditionellen BSDs nur, wenn der Server beim booten seine
Platten / Partitionen nicht umnummeriert, (weil die im gemounteten
Zustand fuer zugegriffene Objekte im Protokill benutzten Filehandles
sowas wie Devicenummern enthalten - das ist aber ein Implementierungsdetail
und koennten OS-Schreiber ändern). 

Aber Umnummerierung war in meiner Jugend selten und laesst sich
auch, besonders heutzutage mit UUIDs mit etwas Willen wegkonfigurieren.

d) Das Problem, dass der Client in standby geht... ich glaube, das
haelt das Protokoll auch aus. Sicherer, besonders was aktualitaet
der Daten angeht, ist man sowieso, wenn man einen automounter
benutzt, der wuerde im autostandby aber eh nicht zuschlagen, weil
die Datei oder das Verzeichnis noch in Benutzung sind.

Ich wuerde es nicht ueber einem WLAN einsetzen, was mir nicht
gehoert. Selbst dann wuerde ich dann NFS ueber (RPC uber) TCP
konfigurieren.  Fragmentverlustee bei 8kb oder 32kb grossen
UDP-Paketen sind haesslich.

	-is

Back to de.comm.protocols.misc | Previous | Next — Previous in thread | Find similar

Thread

Netzwerkdateisystem, was Standby aushält Marco Moock <mm+solani@dorfdsl.de> - 2024-07-24 11:46 +0200
  Re: Netzwerkdateisystem, was Standby aushält Ignatios Souvatzis <u502sou@bnhb484.de> - 2024-12-20 11:56 +0000

csiph-web