RFS

Wprowadzenie

Krótki wstęp

System RFS został stworzony w AT&T. Początkowo działał on na systemie SVR3 UNIX, lecz szybko RFS przebudowano i zintegrowano z interfejsem węzłów wirtualnych (w wersji SVR4). Tutaj omówimy właśnie tę implementację RFS.

Cele projektowe

Podstawowe założenia to:

• przezroczysty dostęp do plików i urządzeń zdalnych
• zachowanie pełnej semantyki UNIXowej
  
  Wspierane są wszystkie typy plików i urządzeń jak np. kolejki FIFO. Możliwe jest nakładanie blokad na pliki.
• zapewnienie zgodności binarnej
  
  Nie trzeba modyfikować istniejących aplikacji.
• niezależność sieciowa
  
  RFS można używać zarówno w sieciach lokalnych jak i rozległych.

Budowa systemu RFS

Architektura RFS

Właściwości architektury RFS:

• model klient-serwer
  
  Serwer eksportuje pliki, które klilenci montują.
• serwer jest stanowy
  
  Jest to konieczne do zapewnienia UNIXowej semantyki plików otwartych. Serwer utrzymuje tablicę wszystkich klientów i przechowuje informacje o stanie plików.
• zastosowano usługę transportową typu obwodu wirtualnego, TCP/IP
  
  Każda para klient-serwer stosuje jeden obwód, który jest tworzony podczas operacji mount.
• zastosowano mechanizm strumieni i interfejs dostawcy transportu TPI
  
  W RFS można stosować wiele strumieni, może być zatem wielu dostawców transportu na jednym komputerze.
• mamy niezależność położenia pliku dzięki nazwom zasobów
  
  Każdy eksportowany katalog plików dostaje symboliczną nazwę zasobu, które są odwzorowywane na faktyczne położenie sieciowe przez scentralizowany serwer nazw.
• są różne protokoły RFS
  
  Początkowo (wersja 1.0) używano modelu zdalnej funkcji systemowej, gdzie serwer odtwarzał środowisko klienta. Następnie (wersja 2.0) wprowadzono zestawy zleceń bezpośrednio odpowiadającym operacjom na v-węzłach. Na początku klient i serwer muszą uzgodnić, którą wersję obsługują.

Rysunek: Komunikacja w RFS.

Implementacja systemu RFS

1. Montowanie

   Operację montowania obsługuje się oddzielnie za pomocą montowania zdalnego. Używany jest wtedy serwer nazw.

   Aby klienci mogli zamontować katalog, serwer musi go najpierw wyeksportować, robi to przy użyciu funkcji advfs (w nowszych wersjach podfunkcji funkcji rfsys). Wywołanie tej funkcji stworzy w liście zasobów jądra odpowiednią pozycję dla zadanego katalogu.

   Rysunek: Lista zasobów w systemie RFS.

   
   Teraz klient może wywołać polecenie mount, w którym najpierw zostanie odpytany serwer nazw o położenie pliku w sieci, a potem zostanie wysłane do zadanego serwera żądanie zamontowania danego pliku bądź katalogu. Jeśli klient ma prawo do korzystania z danego zasobu serwer zwróci identyfikator zamontowania. Klient z kolei, kończy montowanie poprzez konfigurację v-węzła, gdzie zostaje zapamiętana struktura deskryptor przesyłu (ang. send descriptor). W deskryptorze przesyłu pamiętany jest uchwyt pliku i informacje o obwodzie wirtualnym.

   Rysunek: Montowanie systemu plików RFS.

   
2. Klient i serwer RFS

   Klient może odwoływać się do pliku RFS za pomocą nazwy ścieżkowej bądź deskryptora pliku. Ponieważ protokół RFSv2 pozwala na montowanie innych systemów plików na katalogach RFS, to podczas analizy ścieżkowej trzeba analizować każdą składową osobno. Gdy klient uzyska już uchwyt pliku, będzie go zawsze przekazywać przy żądaniu operacji na pliku.
   W serwerze utrzymywana jest dynamiczna pula procesów-demonów, które obsługują każde zlecenie osobno. Gdy przybywa nowe zlecenie tworzony jest nowy proces, gdy nie ma dostępnych. Serwer działa jako jeden lub kilka demonów, które wykonują się w trybie jądra. Demony są szeregowane tak jak inne procesy.

3. Sygnały

   Ponieważ system RFS wspiera całą semantykę UNIXową wprowadzono również możliwość przesłania sygnału. Jądro klienta po otrzymaniu sygnału wysyła do serwera zlecenie sygnału (ang. signal request). Serwer po jego otrzymaniu przekazuje sygnał do właściwego demona.

4. Pamięć podręczna

   Ze względu na wydajność system RFS wspiera buforowanie danych po stronie klienta. Ponieważ jednak semantyka systemu RFS jest UNIXowa, należało zadbać, aby pamięć podręczna klientów była zawsze aktualna. Osiągnięto to dwojako:

   • zapisywanie natychmiastowe (ang. write-through)
     
     Choć pogarsza wydajność jest niezbędne do utrzymania spójności danych.
   • czytanie wszystkich bloków z pamięci podręcznej lub żadnego
     
     Aby zagwarantować niepodzielność funkcji read dane przekazywane są z buforów podręcznych jedynie wtedy, gdy wszystkie bloki są po stronie klienta. Jeśli kawałka pliku brakuje, to cały żądany fragment jest pobierany z serwera.

   O spójność danych pamięci podręcznej dba serwer (jeśli plik jest współdzielony przez wielu klientów) lub klient (jeśli mamy do czynienia ze współdzieleniem przez różne procesy tego samego klienta). Gdy jakiś klient wykona operację write, wtedy rozsyłany jest komunikat do wszystkich innych klientów mających ten plik otwarty, że buforowane dane są nieaktualne. Pozostali klienci czytają dane bezpośrednio z serwera, dopóki plik będzie modyfikowany. Natomiast klient mający plik zamknięty może używać buforowanych danych, gdy numer wersji pliku w buforze zgadza się z tym zwróconym przez serwer w wyniku operacji otwierania.

   Rysunek: Zapewnianie spójności pamięci podręcznej w systemie RFS.