Implementare un server di rete

Un'altra soluzione che comporta un minimo cambiamento al sistema operativo, consiste nell'installare sulla propria macchina un server di rete progettato ad-hoc. Esso soddisfa le nuove richieste attraverso un'interfaccia già esistente e standardizzata, non legata ad un particolare sistema operativo a differenza del VFS di Linux. Un demone così costruito viene detto di loopback ed il suo funzionamento è analogo a quello della precedente soluzione proposta. In questo caso però è lo stesso client NFS disponibile all'interno del kernel che si occupa della comunicazione con il server preposto all'esecuzione delle chiamate di sistema.

I problemi che sorgono da questa soluzione sono numerosi: ogni operazione bloccante eseguita dal server di loopback NFS ha la possibilità di mettere la macchina in uno stato di deadlock^3.4. Questa situazione si può verificare come conseguenza della tipica strategia del kernel per allocare un buffer: su molti sistemi operativi derivati da UNIX $^{\textrm{TM}}$, quando il kernel riempie tutti i buffer disponibili, la funzione di allocazione può selezionare alcuni buffer ``sporchi'' da riciclare, e bloccarsi attendendo che un particolare buffer venga pulito. Se questa pulizia richiede una chiamata al server di loopback ed esso stesso sta attendendo che il kernel termini la pulizia, il sistema passerà in uno stato di deadlock.

I server emulati possono inoltre essere ostacolati dal modo di gestire i client NFS da parte del kernel. Quando un'operazione richiede molto tempo per essere completata, il client trasmette nuovamente la richiesta. Dopo alcune trasmissioni, il client ritiene che ci siano problemi di collegamento con il server. Per evitare l'intasamento di quest'ultimo, esso blocca il punto di mount e le successive richieste e periodicamente invia il messaggio originale. Questo significa che un file ``lento'', può bloccare l'accesso ad altri file gestiti dallo stesso server.

Molte funzioni inoltre richiedono che ogni file del sistema sia rappresentato univocamente da una coppia ( $\texttt{st\_dev, st\_ino}$). Con NFS, invece, il primo valore rimane lo stesso per tutti i file che risiedono all'interno di un determinato punto di mount, quindi, ogni volta che si tenta di raggruppare file da diverse sorgenti, il server di loopback deve assicurarsi che tutti i valori dei campi $\texttt{st\_ino}$ siano differenti.

In ultimo, ma di importanza principale, sebbene questo tipo di applicazione, sia implementata a livello utente, può bloccare il sistema in caso di errori: a volte può essere impossibile anche la disattivazione del file system.

Una soluzione alternativa consiste nella realizzazione di un server che si interfacci al file system CODA. Questo tipo di scelta evita il rischio di deadlock, ma il protocollo CODA supporta esclusivamente l'accesso sequenziale ai file: anche per leggerne il primo byte, il server deve memorizzare tutto il contenuto in un directory di cache. Questa limitazione rende ogni tentativo di sviluppo basato su CODA molto lento e non responsivo. Un esempio di questa implementazione è UserVFS approfondito in [Eat01].

In conclusione, l'implementazione di un server di loopback per file system di rete è interessante per la sua elevata compatibilità, ma impone di risolvere numerose sfide. Nell'articolo [Maz01] vengono presentati una serie di strumenti per poter semplificare la realizzazione di un demone per il protocollo NFS.