[linux-l] lokales Netz - NFS oder Samba?

[Frank Reker]

Am Fri 13. Apr 2007 19:59 +0200 schrieb olafBuddenhagen at gmx.net:

>Mangels Transkationen im Dateisystem-API

wieso? ein open startet eine transaktion und ein close beendet
eine transaktion. man hat keine transaktion ueber mehrere dateien
hinweg, das ist richtig, aber auf datei ebene sehr wohl.


>ist das schwierig, aber wie schon erwähnt machbar, indem man die neue
>Datei erst schreibt, und dann erst an Stelle der alten einhängt. Das
>muss das Programm aber selbst machen; trasparent geht das nicht.

geht schon. beim open wird eine kopie oder ein repository/journal 
angelegt und beim close wieder entfernt. 
problematisch sind hierbei zwei dinge:
1) muss der server sicher sein, dass er auch alle write-instruktionen
erhalten hat. das ist bei nfs nicht gegeben.
2) koennen auch veraenderungen lokal durchgefuehrt werden ohne ueber
die netzwerk schicht zu gehen. dadurch wird ein journaling auf
netz-fs-ebene umgangen.

erstes problem kann man durch ein sauberes netz-protokol beheben.
zweites problem ist deutlich schwieriger. auf der anderen seite,
ist das resultat ohnehin nicht definiert wenn zwei prozesse gleichzeitig
in die selbe datei schreiben. und da unter unix diese problematik
ohnehin auf anwendungsebene verlagert wurde braucht sich imho ein
netz-fs darum auch nicht zu kuemmern.


>> aber je nach mount-option bekommt die applikation ueberhaupt nicht
>> mit, das das rueckschreiben schief gegangen ist. und wenn man z.b. in
>> vi mit ZZ oder :wq schreibt und gleichzeitig vi(m) beendet, dann kann
>> es passieren, dass die datei abgeschnitten ist, und das .swp file
>> trotzdem geloescht wurde, so dass ein recovery unmoeglich wird. und
>> genau das ist mir passiert.
>
>Sollte eigentlich keine Rolle spielen, wenn die Hauptdatei erst
>geschrieben, und erst danach das Swapfile gelöscht wird... Vielleicht
>spielt da Client-seitiges Caching übel mit. Dafür sehe ich keine

nein - der klient bekommt (zumindest in der udp-variante) nicht mit,
wenn durch temporaere netzwerkfehler daten nicht oder nicht vollstaendig
geschrieben wurden. die anwendung muesste also nach dem schreiben
die datei erst nochmal wieder einlesen und ueberpruefen ob's 
vollstaendig ist. bei dem erneuten einlesen muesste die anwendung aber
sicher sein, dass sie nicht aus dem cache liesst, und das kann die
anwendung bei nfs per se nicht wissen. 
der konkrete fall auf den ich mich bezog ist allerdings 8 jahre her. 
server unter hpux und einem client unter linux.
mag sein dass das bei neueren nfs-versionen mittlerweile besser ist?
aber auch nur wenn tcp verwendet wird. unter udp ist soetwas 
prinzipbedingt nicht moeglich (es sei denn man baut sich ne 
transaktionskontrolle auf anwenderebene nach).
da man als looser-user ohne groesseren aufwand nicht unbedingt wissen 
kann wie der nfs-server/client konfiguriert ist, muss man immer von
der schlechtmoeglichsten variante ausgehen, und entsprechende 
massnahmen ergreifen.



-- 
Don't worry be happy ...
Ciao Frank
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: nicht verfügbar
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20070414/73fbaf43/attachment.sig>