Usando Samba - Bloqueos y Opciones de Bloqueos

Los intentos de escritura concurrentes a un mismo archivo no son nada deseables en la mayoría de sistemas operativos. Para prevenir esto, la mayoría de sistemas operativos usan bloqueos para garantizar que sólo un proceso puede escribir sobre un fichero en un determinado instante de tiempo. Tradicionalmente, los sistemas operativos bloquean ficheros completos, aunque algunos permiten bloquear un rango de bytes dentro de un fichero. Si otro proceso intenta escribir sobre un fichero (o sección de fichero) que todavía está bloqueado, este recibirá un error desde el sistema operativo y tendrá que esperar hasta que el bloqueo sea liberado.

Samba soporta las peticiones de bloqueo standard de los sistemas de archivos DOS y NT (deny-mode), los cuales permiten que un sólo proceso pueda escribir sobre un archivo completo en un servidor en un momento determinado de tiempo, así como permiten el bloqueo de rango de bytes. En adición, Samba soporta un nuevo mecanismo de bloqueo conocido en el mundo de Windows NT como bloqueo oportunista (oplock para resumir).

Bloqueo Oportunista

El bloqueo oportunista permite a un cliente notificar al servidor Samba que éste no será el que pueda escribir en exclusiva sobre un fichero, pero también podrá almacenar (en caché) los cambios que haya realizado sobre el fichero en su propia máquina (y no en el servidor Samba) en orden a acelerar el acceso al fichero para ese cliente. Cuando Samba que ese fichero ha sido bloqueado oportunísticamente por un cliente, este lo marca y espera a que el cliente complete su trabajo sobre el fichero, al punto que espera a que el cliente envíe los cambios finales de vuelta al servidor Samba para sincronización.

Si una segunda petición de cliente accede a ese fichero antes de que el primero haya terminado de trabajar con él, Samba puede enviar una petición oplock break (romper bloqueo oportunista) al primer cliente. Este le dice al cliente que pare el almacenamiento en caché de sus cambios y retorne al estado actual del fichero desde el servidor, para que el cliente que interrumpe pueda usarlo sin peligro a cambios posteriores por la parte del otro cliente. Un bloqueo oportunista, sin embargo, no elimina un bloqueo estandar del tipo modo-denegación. Es posible que el proceso que interrumpe consiga una rotura del bloqueo oportunista sólo para encontrarse con que el proceso original también tenía un bloqueo modo-denegación sobre el fichero. La Figura 5.8 ilustra el proceso del bloqueo oportunista.

Figure: Bloqueo Oportunista.

En términos de bloqueos, recomendamos efusivamente el uso de los valores por defecto proporcionados por Samba: bloqueos standard del tipo modo-denegación DOS/Windows para compatibilidad y bloqueos oportunistas para el rendimiento extra que permita la caché local. Si tu sistema operativo puede tomar ventaja de los bloqueos oportunistas, esto te podría proporcionar un aumento del rendimiento. A menos que tengas una razón específica para cambiar cualquiera de estas opciones, es mejor que las dejes como están.

Unix y los Bloqueos

Los sistemas Windows cooperan bien para impedir la pérdida de los cambios realizados. Pero si un fichero almacenado en un sistema Samba es accedido por un proceso Unix, este proceso no entiende nada de bloqueos de Windows, y podría fácilmente saltarse ese bloqueo. Algunos sistemas Unix han sido diseñados para comprender los bloqueos de Windows mantendos por Samba. Actualmente existe el soporte sólo en SGI Irix 6.5.2f y posteriores; Linux y FreeBSD deberían implementarlo pronto.

Si tienes un sistema que entiende estos bloqueos, establece kernel oplocks = yes en el fichero de configuración de Samba. Esto debería eliminar los conflictos entre los procesos Unix y los usuarios Windows.

Si tu sistema no soporta los bloqueos oportunistas a nivel de núcleo, podrías terminar con datos corruptos cuando alguien ejecute un proceso Unix que lea o escriba un fichero al que los usuarios Windows también hayan accedido. Sin embargo, Samba proporciona un mecanismo de protección en ausencia de bloqueos oportunistas a nivel de núcleo: la opción veto oplock files. Si puedes anticipar qué ficheros Samba serán usados tanto por usuarios Windows y Unix, establece sus nombres en una opción veto oplock files. Esto suprimirá el uso de bloqueos oportunistas sobre los ficheros coincidentes, lo cual suprime el cacheado del cliente, y permite a los programas Windows y Unix usar bloqueo de sistema o tiempos de actualización para detectar una pugna por el mismo archivo. Un ejemplo:

veto oplock files = /*.dbm/}
 

Esta opción permite tanto a los procesos Unix como a los usuarios Windows editar archivos que terminen con el sufijo .dbm. Advierte que la sintaxis de esta opción es similar a veto files.

Las opciones de Samba para bloqueos y bloqueos oportunistas los tienes en la Tabla 5.8.

share modes

Los tipos de bloqueo más antiguos disponibles para Samba eran los de modo-denegación, conocidos como share modes, los cuales eran empleados por programas como editores de texto para evitar escrituras accidentales sobre los archivos abiertos. Los bloqueos de modo-denegación se listan en la Tabla 5.9.

El parámetro share modes, el cual refuerza el uso de estos bloqueos, está activado por defecto. Para desactivarlo, usa el siguiente comando:

[accounting] share modes = no

Te recomendamos efusivamente no desactives el mecanismo de bloqueo por defecto a menos que tengas una razón justificada para hacerlo. La mayoría de las aplicaciones Windows y DOS cuentan con estos mecanismos de bloqueo en orden a funcionar correctamente, y echarán de menos esta funcionalidad si la desactivas.

locking

La opción locking puede ser usado para decirle a Samba que establezca o no bloqueos de rango de bytes en la parte del cliente. Samba implementa bloqueos de rango de bytes en el servidor con bloqueos de aviso típicos de Unix y consecuentemente prevendrán a otros procesos Unix contra la escritura de un rango de bytes bloqueado.

Esta opción puede ser especificada por cada recurso como sigue:

[accounting]
   locking = yes
 

Si la opción locking se establece a yes, el peticionario será puesto en espera hasta que el tenedor actual u otro tipo de bloqueo lo libere (o caiga). Si, por el contrario, la opción se establece a no, no se mantendrán ningún tipo de bloqueos de rango de bytes sobre los ficheros, aunque se intenten peticiones de bloqueo y desbloqueo. La opción se establece a yes por defecto; sin embargo, puedes desactivar esta opción si se trata de un medio de sólo lectura.

strict locking

Esta opción chequea cada acceso a fichero buscando bloqueos de rango de bytes en el rango de bytes al que se está accediendo. Esto normalmente no es necesario si un cliente se adhiere a todos los mecanismos de bloqueo. Esta opción se establece a no por defecto; sin embargo, puedes resetear esto por cada recurso como sigue:

[accounting]
   strict locking = yes
 

Si esta opción se establece a yes, los bloqueos mandatorios son reforzados sobre cualquier archivo con bloqueos de rango de bytes.

blocking locks

Samba también soporta bloqueos de bloque, una variante menor de bloqueos de rango. Aquí, si el rango de bytes no está disponible, el cliente especifica una cantidad de tiempo que está dispuesto a esperar. El servidor entonces cachea la petición de bloqueo, chequeando periódicamente para ver si el fichero está disponible. Si lo está, lo notifica al cliente; sin embargo, si el tiempo expira, Samba le dirá al cliente que la petición no pudo ser atendida. Esta estrategia previene contra que el cliente esté contínuamente conectando para ver si el bloqueo está disponible.

Puedes desactivar esta opción por cada recurso como sigue:

[accounting]
   blocking locks = no
 

Cuando se establece a yes, los bloqueos de bloques se reforzarán sobre el archivo. Si esta opción se establece a no, Samba se comporta como si existieran unos mecanismos de bloqueo normales sobre el fichero. El valor por defecto es yes.

oplocks

Esta opción activa o desactiva el soporte para bloqueos oportunistas en el cliente. La opción es activada por defecto. Sin embargo, puedes desactivarla con el siguiente comando:

[data]
   oplocks = no
 

Si estás en un entorno de red altamente inestable o tienes muchos clientes que no puedan tomar ventaja de los bloqueos oportunistas, puede que sea mejor desactivar esta característica en Samba. Lo bloqueos oportunistas deberían ser desactivados si estás accediendo a los mismos ficheros tanto desde aplicaciones Unix (tales como vi ) y clientes SMB (a menos que tengas la suerte de contar con un s.o. que soporte bloqueos oportunistas a nivel de núcleo, como ya comentamos antes).

fake oplocks

Antes de que los bloqueos oportunistas estuvieran disponibles en Samba, los demonios Samba pretendian permitir bloqueos oportunistas a través de la opción fake oplocks. Si esta opción fue activada, todos los clientes fueron avisados de que el fichero está disponible para hacerle bloqueos oportunistas, y nunca se avisará sobre accesos simultáneos. Esta opción ha caido en deshuso ahora que los verdaderos bloqueos oportunistas están disponibles en Samba.

kernel oplocks

Si una aplicación Unix separada de Samba intenta actualizar un fichero que Samba tiene con bloqueo oportunista para un cliente Windows, este tendrá éxito (dependiendo del s.o.) y tanto Samba como el cliente nunca lo advertirán. Sin embargo, si el s.o. Unix local lo soporta, Samba puede advertir sobre los ficheros con bloqueos oportunistas, los cuales pueden suspender el proceso Unix, notificar al cliente vía Samba que guarde su copia del archivo, y sólo entonces permitir la apertura del ficihero. Esencialmente, esto significa que el kernel del sistema operativo del sistema Samba tiene la habilidad de manejar bloqueos oportunistas tan bien como Samba.

Puedes activar esta característica con la opción kernel oplocks, como sigue:

[global] 
   kernel oplocks = yes
 

Samba puede detectar automáticamente bloqueos oportunistas a nivel de kernel y usarlos, si están presentes. Al tiempo de la escritura de este capítulo, esta característica está soportada sólo por SGI Irix 6.5.2f y posteriores. Sin embargo, el soporte para Linux y FreeBSD se espera esté en un futuro próximo. Un sistema sin bloqueos oportunistas a nivel del kernel permitirán a los procesos Unix actualizar el fichero, pero los programas cliente serán notarán el cambio sólo más tarde, en todo caso.

veto oplock files

Puedes proporcionar una lista de nombres de archivos sobre los que nunca se permitirán bloqueos oportunistas con la opción veto oplock files. Esta opción puede ser establecida globalmente o a nivel de recurso. Por ejemplo:

veto oplock files = /*.bat/*.htm/
 

El valor para esta opción es una serie de patrones. Cada entrada del patrón debe comenzar, termianr, o estar separada de otra por una barra (/), aunque sólo haya uno en la lista. Los asteriscos se pueden usar como comodín para representar cero o más caracteres. Las interrogaciones pueden ser usados para representar exactamente un carácter.

Recomendamos que desactives los bloqueos oportunistas sobre cualesquiera ficheros que vayan a ser actualizados por Unix o que vayan a ser compartidos por varios procesos simultáneamente.

lock directory

Esta opción (a veces llamada lock dir) especifica la localización de un directorio donde Samba almacenará ficheros de bloqueo de modo-denegación. Samba almacena otros archivos también en este directorio, tales como listas de navegación y su fichero de memoria compartida. Si WINS está activado, la base de datos WINS se escribe también en éste directorio. El valor por defecto para esta opción es especificado en el makefile de Samba; y suele ser /usr/local/samba/var/locks. Puedes cambiar esta localización como sigue:

[global]
   lock directory = /usr/local/samba/locks
 

Normalmente no necesitarás modificar esta opción, a menos que quieras mover los ficheros de bloqueo a otra localización, tal como /var/spool/locks.