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.
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.
TLDP-ES 03/11/2002