Porównanie Unixowych systemów plików

Cele postawione przed NFSv4:

Czym NFSv4 różni się od NFS?

1. Wprowadzono złożone procedury

• łączy się pewną ilość procedur w jedną złożoną
• mniej wywołań procedur oznacza mniejszy ruch w sieci, zmniejszają się opóźnienia

2. Lepsze umiędzynarodowienie

• nazwy plików i katalogów kodowane w standardzie UTF-8
• możliwość specyfikowania typu kodowania wewnątrz XDR

3. Zmienne uchwyty plików

3a. dawniej

• uchwyt pliku był niezmienny
• składał się m. in. z numeru i-węzła, numeru urządzenia danej partycji dyskowej oraz "generation count"
• i-węzły mogą być zwalniane i relokowane, wtedy generation count jest inkrementowane, tak by klient nie mógł dłużej do tego pliku się odnosić starym uchwytem

4. Wprowadzono klasy atrybutów

• dawniej przesyłane siecią atrybuty były przystosowane dla UNIX-a, w pewnych środowiskach niektóre były bez znaczenia, nie zawsze serwer mógł dostarczyć prawidłowe wartości
• wprowadzono więc klasy atrybutów:

5. Lepsze wykorzystanie przestrzeni nazw

• dawniej serwer eksportował zbiór niezależnych obszarów swej całkowitej przestrzeni nazw i nie pozwalano klientom przekraczać punktów montowania na serwerze, ponieważ NFS chciał wszystkie operacje wyszukiwania (lookup) wykonywać wewnątrz jednego systemu plików
• teraz mamy pojedynczy "root file handle", przez który klienci mogą otrzymać uchwyty plików
• serwery mogą być łatwiej przeglądane poprzez połączenie wyeksportowanych poddrzew przestrzeni nazw w pseudo-systemem plików i zezwolenie klientom przekraczania punktów montowania na serwerze

6. Pseudosystem plików

• jest to mechanizm prezentacji klientowi tego co serwer eksportuje
• definiowana jest specjalna operacja pozwalająca uzyskać "root filehandle", który reprezentuje najwyższy poziom w pseudosystemie
• każda rzecz wyeksportowana przez serwer jest katalogiem w pseudofs
• pozwala przeglądać wyeksportowane rzeczy bez potrzeby używania dodatkowych protokołów
• w standardzie NFSv4 nie ma wyspecyfikowanej relacji między nazwami w pseudofs oraz właściwymi nazwami w eksportowanych katalogów na serwerze

7. Blokowanie plików

• dawniej protokół NFS nie obejmował blokowania; było ono częścią osobnego protokołu NLM (Network Lock Manager), który nie był jednak powszechnie stosowany
• NFSv4 dostarcza zarówno unixowe funkcje blokujące dla plików, jak i oparte na Windowsie funkcje blokowania dzielonego, wspiera zarówno funkcje blokowania rekordów jak i zakresu bajtów
• windowsowa semantyka blokowania dzielonego wymusza atomowość operacji open i close

8. Stany

• NFSv4 jest stanowy
• stany przechowują informacje o otwartych plikach (głównie by wspierać windowsową semantykę dzielonych rezerwacji), blokadach, delegacjach
• delegacje mogą być np. do czytania - serwer gwarantuje, że nikt inny nie pisze; do pisania - nikt inny nie ma dostępu, itp.
• scenariusz awarii serwera i jego restartu:

9. Użycie pamięci podręcznej u klienta

• w zwykłym NFS klient przechowuje w cache-u wszystko (dane plików, atrybuty) i jak najwięcej
• NFSv4 dostarcza plan upoważniania (delegation scheme), który pozwala klientom podejmować decyzje tradycyjnie będące w gestii serwera (co ogranicza ilość wywołań procedur systemowych)
• w NFSv4 klient może trzymać w cache-u stany blokowań
• klient może poprosić serwer o oddelegowanie mu odpowiedzialności za zmiany atrybutów pliku, danych lub blokad
• jeśli inni klienci próbują uzyskać dostęp do pliku serwer przywoła posiadacza delegacji na dany plik; tenże zapisze zmodyfikowane dane i odpowie (umożliwi innym dostęp do pliku)

• wbudowane są różne rodzaje delegacji uprawnień, więc co za tym idzie też różne sposoby używania cache-a po stronie klienta

10. Wbudowane bezpieczeństwo

• nie ma protokołu Mount
• obowiązkowe użycie silnych mechanizmów bezpieczeństwa RPC, opartych na kryptografii; NFSv4 używa RPCSEG_GSS; jest to mechanizm mogący dostarczać schematy kluczy prywatnych (np. Kerboros version 5) i publicznych
• negocjowanie bezpieczeństwa - nowa operacja SECINFO, która pozwala klientowi zapytać serwer, jakie środki bezpieczeństwa wymaga serwer dla danego pliku. Argumenty i wyniki tej operacji są zabezpieczane przy użyciu podstawowego poziomu zabezpieczeń(mandatory security flavors). Wynikiem operacji jest zdefiniowanie poziomów zabezpieczeń RPC, oraz dodatkowych związanych z tym informacji (jeśli wymagane) takich jak: identyfikator obiektu dla mechanizmu GSS-API, jakość zabezpieczeń, czy używać autoryzacji, integralność (sumy kontrolne argumentów), prywatność (zakodowane argumenty i wyniki)
• używanie napisów zamiast integerów dla reprezentowania identyfikatorów użytkowników i grup (np. 'user@domain', 'group@domain' )
• łatwa komunikacja przez firewall-e:

• kontrola dostępu, która jest kompatybilna z UNIX-em i Windows-em

11. NFSv4 udostępnia się różnym internetowym aplikacjom

• ściąganie dużych plików poprzez FTP lub HTTP, często kończy się porażką (np. timeout) i trzeba zacząć od początku
• NFSv4 jest dużo lepszym protokołem dostępu do plików, ponieważ umożliwia klientom czytanie z dowolnym offsetem (jeśli wystąpi błąd można wznowić połączenie i kontynuować od miejsca, gdzie się skończyło)

RFS (Remote File Sharing) - wprowadzony w 1986 przez AT&T

Cele - umożliwienie przezroczystego dostępu poprzez sieć do zasobów dyskowych i urządzeń zewnętrznych na płaszczyźnie UNIX-a

Architektura RFS:

• model klient-serwer
• Serwer - udostępnia swój system plików lub swoje urządzenia zewnętrzne (eksportuje)
• Serwer eksportując zasoby publikuje ich nazwy na serwerze nazw
• Serwer może eksportować

• Klient - korzysta z odległych zasobów (montuje system plików) identyfikując je poprzez nazwę
• Klient może dowiedzieć się z serwera nazw gdzie znajduje się interesujący go zasób
• Oprócz głównego serwera nazw, mogą być pomocnicze serwery nazw, które w przypadku awarii serwera głównego przejmują jego rolę
• Możemy wprowadzić dziedziny - jednostki administracyjne

• RFS potrzebuje osobnego protokołu serwisu nazw, żeby zarządzać wszystkimi zasobami

• RFS bazuje na protokole RPC

• XDR używany do kodowania typów danych, ale tylko jeśli różnią się architektury maszyn klienta i serwera

• Po stronie serwera emulowane jest środowisko klienta

• RFS jest stanowy (by móc zapewnić pełną unixową semantykę operacji na plikach)

• RFS potrzebuje solidnego protokołu transportu, oferującego tryb kontroli połączenia (np. TCP). W obrębie komputera stosowany jest mechanizm strumieni

Użycie cache-a

• RFS implementuje pisanie bez opóżnień z cacha na serwerach (write-through)
• Używanie cache-a po stronie klienta dla danego pliku jest wyłączane w sytuacjach gdy inny klient wykona na tym pliku write i trwa do chwili aż go zamknie, lub minie określony okres czasu.

Różnice między RFS a NFSv2:

• NFSv2 jest bezstanowy, a RFS jest stanowy, potrzebuje głównego serwera nazw do koordynowania jego działania
• RFS jest bezpieczniejszy, oferuje takie mechanizmy jak
  • hasła: może być przypisywane zasobom, zarządza nimi serwer nazw
  • ograniczenia dostępu (dostęp dla niektórych użytkowników, dostęp tylko do czytania)
  • tablice odwzorowań łączące identyfikatory użytkowników po stronie klienta i serwera definiowane przez serwery eksportujące zasoby

  W NFSv2 natomiast zgodność numerów identyfikatorów

• RFS umożliwia dostęp przez sieć do odległych urządzeń zewnętrznych, podczas gdy NFSv2 nie
• RFS umożliwia komunikację miedzy odległymi procesami za pomocą plików FIFO, podczas gdy NFSv2 nie
• W RFS nazwy zasobów są publikowane na serwerze nazw, podczas gdy w NFSv2 nie ma czegoś takiego
• RFS jest w pełni zgodny z unixową semantyką operacji na plikach, podczas gdy w NFS-ie wer. 2 nie jest zdefiniowane blokowanie plików i ich części
• NFS może działać w heterogenicznych środowiskach podczas, gdy RFS jest zawężony tylko do środowisk UNIX-owych
• Użytkownik NFS-a musi znać nazwę komputera z którego chce pobrać plik, podczas gdy w RFS-ie nie musi
• RFS ma zaimplementowane montowanie tylko soft, podczas gdy NFS zarówno soft jak i hard; w RFS nie ma automontowania (w przeciwieństwie do NFS)
• NFSv2 ma lepszą wydajność
• RFS dostępny jest tylko na komputerach Sun i AT&T
• NFS jest dużo bardziej rozpowszechniony (właściwie dziś RFS rzadko gdzie jeszcze występuje)

Bibliografia