| Siguiente: Detalles de implementaci�n Superior: Mejorando NFS Anterior: Introducci�n b�sica a NFS |
Nuestro objetivo, pues, era a�adir una operaci�n llamada copy que tuviese iguales resultados que read y write, que cumpliese las restricciones de dise�o de NFS y que, a ser posible, fuese compatible hacia atr�s con los servidores y clientes sin modificar.
Para ello tuvimos que modificar dos elementos, por un lado el cliente, dentro del kernel, (para lo que utilizamos la versi�n 2.2.12 del kernel de Linux) para dar acceso a nuestra nueva operaci�n. Por otro lado, tuvimos que modificar tambi�n el servidor de NFS para atenderla (para lo que utilizamos la versi�n 2.2beta37, un servidor de espacio de usuario, pues el de espacio de kernel estaba todav�a en estado experimental).
Aunque en un principio pensamos en crear una nueva llamada al sistema para dar acceso a nuestra operaci�n, finalmente nos dimos cuenta de que existe una operaci�n con un interfaz id�ntico al que quer�amos construir, pero dise�ada para trabajar en local. Se llama sendfile y copia de un descriptor de fichero a otro. Fue dise�ada con sockets y servidores web en mente, para resolver un problema homomorfo al que nosotros intent�bamos resolver. Sirve para evitar cambios de dominio al servir paginas web, copiando de un fichero a un socket sin cambiar de dominio (entre kernel y usuario) ni utilizar memoria innecesariamente.
Tras adoptar la llamada al sistema sendfile, la arquitectura qued� m�s o menos clara. El punto de entrada en el kernel era la llamada a sendfile, que a su vez llama a una operaci�n del fichero llamada copy si est� definida. Esta operaci�n solo esta definida si el fichero es de NFS. La operaci�n de copy llama a la RPC del mismo nombre. El servidor atiende a la petici�n haciendo read y write de forma local. Si el fichero no es de NFS se copia normalmente, como si se hubiese llamado a sendfile sin que esta tuviese ninguna de nuestras modificaciones.
Si hemos modificado el servidor, pero el cliente es un cliente normal de NFS, simplemente nadie llamar� a la operaci�n de copy y no habr� ning�n problema.
El problema real aparece cuando es el cliente el que ha sido modificado y no existe esa operaci�n en el servidor. En este caso, si no hubi�semos hecho nada, la RPC habr�a vuelto con un IO error y el cliente se habr�a quedado reintentando.
Con el fin de resolver este problema, hemos hecho que io error sea sin�nimo de operaci�n no implementada. En el caso de un io error, la operaci�n de copy se deshabilita y el cliente deja de usarla, volvi�ndose autom�ticamente compatible hacia atr�s. Si el error era realmente un io error, el segundo intento fallar� y se comportar� como el cliente de NFS sin modificar.
Hay un problema con esta aproximaci�n y es que si realmente hay un io error, la operaci�n de copy deja de usarse. La soluci�n a esto ser�a mantener una cache con el estado del ordenador remoto, mirando si se ha usado o no la operaci�n de copy y si responde a la operaci�n nula (con el fin de si realmente hay un io error) en caso afirmativo.
En el estado actual la operaci�n de copy se deshabilita y habr�a que volverla habilitar. Esto se puede conseguir haciendo uso de un fichero que creamos en /proc. Aun as�, es cierto que se pueden causar problemas en redes con un alto �ndice de errores, en las que simplemente dejar�a de usarse la operaci�n copy.
