MMAP auf NFS und andere Netzwerk- und Verteilte Dateisysteme ist nicht möglich.
Problem: Wenn zwei Betriebsmittelumgebungen/ Prozesse auf zwei Rechnern einen Speicherbereich gemappt haben, so ist der Wunsch, daß bei Änderungen von einem der andere sofort die Änderung mitbekommt, so wie das auf einem Rechner der Fall ist. Dieses zu Realisieren würde einen erheblichen Aufwand mit sich bringen: jeder Schreibzugriff einen Multicast
Wenn man dieses will, so sollte man grundsätzlich umdenken: Dann braucht man kein Netzwerk-Dateisystem, sondern einen Verteilten Speicher, wo die Platten nur noch zur Auslagerung genutzt werden, m.a.W der Hauptspeicher dient als Cache.
Das Kohärenz-Problem aber bleibt. Man löst dieses, in dem man schwächere Modelle verwendet. Meist müssen ja ohnehin Koordinationsmechanismen, d.h. Sperren gesetzt werden, in diesem Fall ist es auch nicht sinnvoll, daß andere etwas von der Änderung mitbekommen. Man denke auch an Transaktionen und damit an konsistente Zustände.
Diese Überlegungen zeigen, daß die Anwendung Hinweise geben muß (hilfsweise kann auch das Betriebssystem auch Charakteristiken sammeln)
Anderseits muß man sich auch die Absicht klar machen: Der Endanwender soll seine Anwendungsprogramme ohne Änderung in einer anderen Umgebung laufen lassen können, damit seine Investitionen geschützt sind.
Sehr vernünftig und effizient ist es, Anwendungen so zu bauen, daß sie verteilt sind.
Z.B. bei Datenbanken sollte man auch auf der SQL-Ebene zugreifen. Bei Quellcode ist mit CVS es möglich, die Versionen und zusammenhänge zentral zu verwalten und sich lokale Schnapshots zu machen.
Dokumentverwaltungen (z.B. im Kaufmännischen Bereich: Briefe, Rechnungen und dergl. ) lassen sich auch einfacher auf einem Server indizieren und verwalten und z.B über HTTP mit Browsern auf den Arbeitsstationen betrachten. Dabei ist es ja noch so, das seltenst geändert wird (Postscript,PDF fast nie)
---> Moral von der Geschicht:
Man muß beim konzeptionellen Einsatz immer nachdenken.
Die Überlegungen zeigen, das Dateiserver wohl hauptsächlich zur
Überbrückung dienen, bis dann Netzwerkfähige Lösungen kommen.
Gegenbeispiel: Threads sind ohne Betriebssystemunterstützung sehr mühsam, z.B. Wenn Systemcall blockiert, soll nicht ganze Anwendung blockiert sein.