Si Coda se está ejecutando en un cliente, se toma para el ejemplo una estación de trabajo Linux, escribiendo mount se mostrará qué sistema de ficheros (de tipo Coda) está montado bajo /coda. Todos los archivos que cualquiera de los servidores pueden proveer al cliente, están disponibles bajo este directorio, y todos los clientes ven el mismo espacio de nombres. Un cliente se conecta a Coda y no a servidores individuales, que entran en juego de manera transparente.Esto es diferente de la manera en que se monta un sistema de ficheros NFS, en cuyo caso se montan sistemas de ficheros por servidor. En un sistema más usual como Windows (Novell y CIFS) tambien con Appleshare en Macintosh , también los archivos se montan por volumen. El espacio global de nombres no es nuevo. El sistema de ficheros de Andrew (Andrew file system, AFS), predecesor de Coda, fué pionero en la idea de almacenar todos los ficheros bajo el directorio /afs. De manera similar, el sistema de ficheros distribuido DSF/DCE de la OFS, monta sus ficheros bajo un directorio. El nuevo sistema de archivos distribuidos de Microsoft (dfs) provee enlaces para poner todo lo compartido por los servidores bajo un único árbol de directorios, parecido al tipo de enlace provisto por los demonios de auto montaje (auto-mount) de unix y el servicio de páginas amarillas. ¿ Por qué se obtienen tantas ventajas de un único punto de montaje ? Porque esto significa que todos los clientes pueden ser configurados de la misma manera, y que los usuarios siempre verán el mismo árbol de directorios. Para grandes instalaciones esto es esencial. Con NFS el cliente necesita una lista actualizada de los servidores y de los directorios que estos exportan, mientras que con Coda un cliente meramente necesita saber donde encontrar el directorio raíz de Coda /coda. Cuando se añaden nuevos servidores o recursos compartidos, el cliente los descubrirá automaticamente en algún lugar bajo el árbol /coda.
Para comprender cómo Coda puede funcionar cuando las conexiones de red han sido servidas, se analizará una operación simple del sistema de ficheros. Supongamos que se escribe: "cat /coda/tmp/foo" para mostrar el contenido de un archivo Coda. ¿ Qué ocurre actualmente ?. El programa cat realiza unas pocas llamadas al sistema con relación al archivo.Una llamada al sitema es una operación a través de la cual un programa pide un servicio del núcleo. Por ejemplo, cuando se abre un archivo, el nucleo realizará una operación de búsqueda para encontrar el inode del archivo y devolverá un identificador de archivo asociado al programa que hizo la petición. El inode contiene información sobre cómo se accede a los datos del archivo, y esta infomación es usada por el núcleo, (el identificador del fichero) es necesario para que el programa pueda abrirlo. La llamada open hace entrar al núcleo en el sistema virtual de ficheros (VFS) y cuando este detecta que la petición es para un fichero en el sistema de ficheros /coda es manejada por el módulo del sistema de ficheros Coda en el núcleo. Coda es un módulo de sistema de ficheros con un tamaño mínimo: mantiene una caché de peticiones respondidas recientemente desde el VFS, pero por otra parte pasa la petición al administrador de la caché de Coda, denominado Venus. Venus buscará en la caché de disco del cliente a /tmp/foo, y en caso de que no esté presente contactará con los servidores para pedir a /tmp/foo. Cuando se localiza el archivo, Venus responde al núcleo, que devuelve el control al programa que realizó la llamada al sistema. Todo el proceso se muestra de manera esquemática en la ficgura Cliente/Venus/Vice.
La figura muestra cómo un programa usuario pide un servicio del núcleo a través de una llamada al sistema. El kernel la pasa a Venus, permitiendole leer la petición desde el dispositivo de caracteres /dev/cfs0. Venus trata de resolver la petición buscando en su caché, preguntando a los servidores o posiblemente declarando desconexión y sirviendola en modo desconectado. El modo desconectado entra en funcionamiento cuando no hay conexión de red a cualquier servidor que tenga ficheros. Esto ocurre tipicamente cuando los clientes se desconectan de la red o cuando existen fallos de red.Si la operación falla por una desconexión de los servidores tambien entraría en funcionamiento.
Cuando el núcleo pasa la petición de apertura a Venus por primera vez, Venus obtiene el fichero entero desde los servidores, usando llamadas a procedimientos remotos para contactar con ellos. Entonces almacena el archivo como un contenedor en la zona de caché (actualmente /usr/coda/venus.chache). El archivo es ahora un archivo normal en el disco local, y las operaciones de lectura y escritura no llegarían a Venus y serían manejadas de manera completa por el sistema de ficheros local (ext2 en Linux). Las operaciones de lectura/escritura de Coda funcionarán a la misma velocidad que en los archivos locales. Si el fichero se abre por segunda vez, no se traerá de los servidores otra vez y la copia local estará disponible para su uso inmediatamente. Los archivos de directorio (recordemos que un directorio es únicamente un archivo) así como todos los atributos (dueños, permisos y tamaños) son todos cacheados por Venus y Venus permite que las operaciones puedan continuar sin contactar con el servidor si los archivos están presentes en la caché. Si el archivo se ha modificado y ha sido cerrado, entonces Venus actualiza los servidores enviándoles el nuevo archivo. Otras operaciones que pueden modificar el sistema de archivos, como la creación de directorios, el borrado de archivos o directorios y la creación o borrado (simbólico) de enlaces, también son propagadas al servidor.
Como se puede apreciar, Coda cachea toda la información que necesita en el cliente y sólo informa al servidor de los cambios que deben realizarse al sistema de ficheros. Los estudios han demostrado que las modificaciones son bastante menos habituales que el acceso "Sólo de lectura" a los ficheros. Estos mecanismos para cachear datos de una manera "agresiva" fueron implementados en AFS y DFS, pero muchos otros sistemas tienen un sistema de caché más rudimentario. Se verá a continuación cómo Coda mantiene la consistencia, pero primero indaguemos que más se necesita para soportar el funcionamiento desconectado.
El origen del funcionamiento desconectado en Coda en una de las características originales del proyecto: proveer un sistema de ficheros con capacidad de recuperación ante fallos de red. AFS, que soportó miles de clientes al final de los ochenta en el campus de la CMU, se volvió tan grande que los retrasos en la red y los fallos del servidor ocurrían en cualquier lugar cada día provocando numerosas molestias.
Se vió en la sección anterior, que Coda cachea toda la información que necesita en el cliente para proveer acceso a los datos. Cuando se realiza una actualización del sistema de ficheros esta debe propagarse al servidor. En el modo conectado normal, esas actualizaciones se propagan de manera síncrona al servidor, esto es, cuando la actualización es completada en el cliente, esta también se ha hecho en el servidor. Si un servidor no está disponible o si las conexiones de red entre el cliente y el servidor fallan, la operación recibirá un error de time-out y fallará. Algunas veces no se podrá hacer nada. Por ejemplo, intentar obtener un archivo que no está en la caché desde los servidores sin conexión de red es imposible. En esos casos el error se enviará al programa que realizó la llamada. Sin embargo, el time-out puede manejarse a menudo de una forma elegante, como se detalla a continuación.
Para soportar ordenadores desconectados u operar ante la presencia de fallos de red, Venus no enviará informes de los fallos al usuario cuando una actualización obtenga un time-out. En lugar de eso, Venus se dá cuenta de que el servidor en cuestión no está disponible, y que la actualización deberá ser registrada en el servidor. Durante la desconexión, todas las actualizaciones se almacenan en el CML, el registro de modificaciones del cliente, que es salvado frecuentemente en el disco. El usuario no se dá cuenta de que Coda ha cambiado a modo desconectado. Una vez que se han reconectado los servidores, Venus reintegrará el CML: pedirá a los servidores repetir las actualizaciones del sistema de ficheros local en el servidor, llevando de ese modo el servidor al estado actual. Además el CML está optimizado, por ejemplo, el ignora las operaciones sobre un fichero que ha sido creado y posteriormente borrado.
Hay otros dos resultados de profunda importancia para el funcionamiento desconectado. El primero que hay es el concepto de acumulación de archivos . Desde que Venus no puede servir un fallo en el caché durante una desconexión, podría ser apropiado que mantuviera ciertos archivos en la caché actualizados, pidiendo frecuentemente al servidor que le envíe las últimas actualizaciones si es necesario. Esos archivos importantes están en las bases de datos de acumulación de los usuarios (que pueden ser construidas automaticamente "espiando" en los accesos a archivo de los usuarios). Actualizar los archivos acumulados se denomina el recorrido de acumulación. En la práctica nuestros ordenadores acumulan enormes cantidades de software del sistema, como los binarios y bibliotecas del sistema de ventanas X11 o Wabi y Microsoft Office.
El segundo resultado es que durante la reintegración podría aparecer que durante la desconexión otro cliente ha modificado el archivo varias veces y debe el archivo debe transportarse al servidor. Esto se denomina un conflicto local/global y necesita repararse. Algunas veces, las reparaciones pueden realizarse automaticamente por las aplicaciones especificas preparadas para ello (que saben que si un cliente ha insertado una cita para el lunes en el archivo del calendario y otro cliente ha insertado una cita para el martes, ésto no ha creado un conflicto irresoluble). Algunas veces, pero muy infrecuentes, se requiere la intervención de una persona para reparar el conflicto.
Así el viernes alguien deja la oficina con bastante código fuente acumulado en el portatil. Después de estar codificando en una cabaña en las montañas, el cruel retorno a la oficina el lunes (diez dias después desde luego), comienza con la reintegración de las actualizaciones realizadas durante el fin de semana. La computación ambulante ha nacido.
En muchos sistemas de ficheros de red el servidor disfruta de una estructura estándard de archivos y exporta un directorio a los clientes. Tal directorio de archivos en el servidor puede ser montado en el cliente y se denomina un recurso compartido en la jerga de Windows y un sistema de ficheros en red en el mundo Unix. Para muchos de esos sistemas no es práctico montar más sistemas distribuidos dentro de los volúmenes de red montados. Se pone especial cuidado y atención en la distribución de las particiones del servidor, sus directorios, y sus recursos compartidos. La organización de Coda (y AFS) difiere de manera sustancial.
Los archivos en los servidores Coda no se almacenan en un sistema de ficheros tradicional. La organización es como sigue. Las particiones en los ordenadores servidores Coda pueden ponerse como disponibles al servidor de ficheros. Esas particiones contendrán archivos que son agrupados en volúmenes. Cada volumen tiene una estructura de directorios como en un sistema de ficheros, esto es: un directorio raíz del volumen y un árbol bajo el. Un volumen completo es mucho más pequeño que una partición, pero mucho mayor que un simple directorio y es una unidad lógica de archivos. Por ejemplo, el directorio home de un usuario podría ser normalmente un único volumen Coda y de manera similar los fuentes de Coda podrían residir en un único volúmen. Tipicamente un único servidor puede tener varios cientos de volúmenes, quizás con un tamaño medio de aproximadamente 10Mb. Un volumen es una cantidad manejable de datos de archivos que es una unidad muy natural desde la perspectiva de la administración del sistema y se ha demostrado bastante flexible.
Coda mantiene información sobre los volúmenes y los directorios, las listas de control de acceso, y los atributos de los ficheros en particiones crudas(sin formatear). Estas son accedidas a través de un registro basado en el paquete de memoria virtual recuperable (RVM) para una mayor velocidad y consistencia. Sólo los datos de los ficheros residen en los archivos de las particiones del servidor.El RVM ha sido construido para que soporte transacciones, esto significa que en caso de que el servidor se estropee el sistema puede restaurarse a un estado consistente sin mucho esfuerzo.
Un volumen tiene un nombre y una identificación y es posible montar un volumen en cualquier lugar bajo /coda. Por ejemplo, para montar el volumen u.braam en /coda/usr/braam, se utiliza el comando cfs makemount u.braam /coda/usr/braam. Coda no permite que los puntos de anclaje sean directorios existentes, ya que se creará un nuevo directorio como parte del proceso de anclaje (o montaje). Esto elimina la confusión que se puede crear al montar sistemas de ficheros Unix sobre directorios existentes. Mientras parece muy similar a la tradición en Macintosh y Windows de crear "unidades de disco y volúmenes" de red, la diferencia principal es que el punto de anclaje es invisible al cliente: este aparece como un directorio ordinario bajo /coda. Un único volumen disfruta del privilegio de ser un volumen raíz, es el volumen que es montado en /coda en el momento de la inicialización.
Coda identifica un archivo por un vector de tres enteros de 32 bits denominado Fid: consiste de una identificación de volumen (VolumeId), una identificación de inodo (VnodeId) y un identificador único. El identificador de volumen identifica el volumen en que reside el archivo. El identificador de inodo es el número de inodo del archivo. El vector Fid es único en un cluster de servidores Coda.
Coda tiene servidores de replicación de lectura/escritura, por ejemplo, un grupo de servidores puede ofrecer datos de archivos a clientes y generalmente las actualizaciones se hacen a todos los servidores del grupo. La ventaja de este sistema es una mayor disponibilidad de los datos: si un servidor falla, otro tomará el control sin notificar al cliente el fallo. Los volúmenes pueden almacenarse en un grupo de servidores denominados VSG (Volume Storage Group, Grupo de almacenamiento de Volúmenes).
Para volúmenes replicados el VolumeId es un VolumeId replicado. La identificación del volumen replicado lleva ligada un VSG y un volumen local en cada uno de los miembros.
El VSG es una lista de servidores que mantiene una copia del volumen replicado.
El volumen local para cada servidor define una partición y un VolumeId que mantiene los archivos y metadatos en ese servidor.
Cuando Venus desea acceder a un objeto en los servidores, primero necesita encontrar la información del volumen VolumeInfo para el volumen que contiene el archivo. Esta información contiene la lista de los servidores y los identificadores de los volúmenes locales de cada servidor cuyo volumen es conocido. Para los archivos la comunicacón con los servidores de un VSG es read-one, write-many ( leer-uno, escribir-muchos), esto es: lee el archivo de un servidor único en el VSG y propaga los datos a todos los miembros del VSG disponibles, el AVSG. Coda puede emplear multicast RPCs, para que as¡ escribir muchas (write-mamy) actualizaciones no sea una penalización para las prestaciones del servidor.
La sobrecarga de la primera vez que se tiene que obtener la información del volumen es enga¤osa tambien. Aunque hay un tiempo para la búsqueda de la información del volumen, los subsiguientes accesos a los archivos disfrutan de un camino mucho más corto desde que el acceso desde la raíz del volumen.
La replicación de servidores como el funcionamiento desconectado tiene dos aspectos que necesitan presentarse: la resolución y la reparación. Algunos servidores en el VSG pueden particionarse a través de la red o por fallos de servidores. En ese caso el AVSG algunos objetos será mas pequeño estrictamente que el VSG. Las actualizaciones no se pueden propagar a todos los servidores, sólo los miembros del AVSG, de esta forma introducen confictos globales.
Antes de obtener un objeto o sus atributos, Venus requerirá la versión marcada de todos los servidores disponibles. Si detecta que algún servidor no tiene la última copia de los archivos, inicia un proceso de resolución que tratará de resolver automaticamente esa diferencia. Si esto falla, un usuario deberá reparalo manualmente. La resolución, iniciada por el cliente, es manejada enteramente por los servidores.
Los servidores de replicación y resolución son maravillosos. Si se sufren fallos de disco de vez en cuando en algunos servidores, para reparar el servidor, todo lo que se necesita e instalar un nuevo disco y decirle a Coda que lo resuelva. El sistema de resolución construye el nuevo disco actualizado basandose en el resto de servidores.
Coda está constantemente activo en el CMU. Muchos clientes lo usan para el trabajo de desarrollo (de Coda), como una propuesta general para el sistema de archivos y para las aplicaciones desconectadas específicas. En los dos escenarios siguientes están explotando las características de coda con mucho éxito. En el CMU se han comprado varias licencias de Wabi (un emulador de windows para Unix) y algún software de windows asociado. Wabi permite a los usuarios ejecutar Ms. Powerpoint y otros programas. Se ha almacenado Wabi, Windows y Ms. Office en Coda, y son compartidos por los clientes. Desde luego, los archivos .ini con las preferencias de un usuario determinado son particulares, pero muchas bibliotecas y aplicaciones no lo son. Mediante el uso de la acumulación de ficheros, se puede continuar usando el software para presentaciones realizadas en ordenadores portátiles. Esto se hace frecuentemente en las conferencias.
Se ha usado durante años sin perdidas de datos de los usuarios. Algunas veces los discos de los servidores han fallado, pero como todos los volúmenes están replicados, se replaza el disco con uno vacío y se invoca al mecanismo de resolución para actualizar el servidor reparado. Todo lo que se necesita para hacer esto es escribir ls -lR en el 'arbol de directorios afectado cuando se ha colocado el nuevo disco. La usencia del archivo en el servidor reparado será notificada y la resolución transportará los archivos de los servidores en buen estado al servidor reparado.
Hay un número de obligadas aplicaciones futuras donde coda podría proveer significantes beneficios.
Los mirrors de FTP deberían ser clientes Coda. Por ejemplo, tomemos ftp.redhat.com, que tiene varios mirrors. Cada mirror activa un programa en Perl que recorre el árbol de directorios completo de RedHat para ver qué se ha actualizado y obtenerlo, aunque esto no sea necesario. Por el contrario, si RedHat almacenara su area FTP en Coda, los mirrors se convertirían en clientes, (sólo RedHat tendría permiso de escritura) y cuando se actualizara un paquete, los servidores Coda notificarían a los mirrors que el archivo ha cambiado. El mirror obtendría este paquete de los servidores, pero sólo la próxima vez que alguien intente obtener ese paquete.
Los servidores de replicación de WWW deberían ser clientes Coda. Muchos proveedores de servicios de internet estan luchando con sólo unos pocos servidores de replicación de WWW. Tienen demasiados accesos para para usar un único servidor http. Usar NFS para distribuir los documentos que se van a servir, se ha mostrado problemático debido a problemas con las prestaciones, así que la copia manual de archivos a servidores individuales se realiza de manera frecuente. Coda podría resolver esto, ya que cada servidor podría ser un cliente Coda y mantener los datos en su caché. Esto provee velocidades de acceso similares a las de un disco local. Si se combina esto con que los clientes del ISP actualizan su información offline, se obtiene una buena aplicación para clientes móviles tambien.
Los ordenadores de una red podrían utilizar Coda como una caché usada para mejorar las prestaciones de una manera drástica. Las actualizaciones en los ordenadores de la red podrían ser hechas automáticamente cuando se convierten en servidores disponibles, y gran parte del ordenador, podría funcionar sin tráfico de red, incluso después de un rearranque.
Los esfurzos actuales en Coda son en su mayoría para mejorar la calidad de Coda. Los ásperos límites , que inevitablemente aparecen con los sistemas en investigación son lentamente suavizados. Se añadirá a Coda una caché de tipo write-back que le permitirá funcionar mucho más rápido. El funcionamiento desconectado es una forma extrema de escritura write-back en el caché, y se está aprovechando el conocimiento de esos mecanismos para realizar escrituras write-back durante el funcionamiento conectado. Tambien se está añadiendo soporte para Kerberos. Los protocolos de red que soportan Coda se estan haciendo tan sencillos como es posible. Sería interesante tener celdas que permitieran a los clientes conectarse a más de un cluster Coda simultaneamente. Las distintas traducciones que se están realizando para distintas plataformas permitarán a muchos sistemas distintos usar Coda.
