La documentación de Perl 5.x establece que su implementación de flock (..) utilizará una de las siguientes llamadas nativas, comenzando en 1 y trabajando hacia 3 si no está disponible:
- rebaño (2)
- fcntl (2)
- lockf (3)
Esta bien. Sin embargo, es posible que haya notado su descargo de responsabilidad de que el lote (2) no debe usarse sobre un NFS. El documento sugiere usar una bandera -Ud_flock para obligar a Perl a usar flock (2). La página de manual de flock (2) (en Redhat) establece un descargo de responsabilidad similar sobre los problemas de NFS.
Mi pregunta es, ¿por qué? Parece que no puedo encontrar un artículo en profundidad o una explicación de POR QUÉ el lote (2) no es seguro en un NFS.
He escrito varios scripts de prueba en C y Perl, tanto en Redhat (donde se usa flock (2)) como en Solaris (donde se usa fcntl (2)). Ejecuté strace / truss para asegurarme de que Perl estaba usando flock (2) y fcntl (2) respectivamente. ¡No pude replicar ningún problema en el que no se respetara un bloqueo! ¿¿Lo que da??
fuente
Estoy bastante seguro de que está analizando los problemas heredados. Recuerde que el manual de Perl5 fue lanzado en 1994 y que era solo una edición del manual de Perl4 de 1991. En esos días, probablemente se podría decir sobre el sistema de archivos Nightmare, que a menudo se llama "no es qué tan bien baila el oso lo que sorprende, pero que baila en absoluto ".
El NFS2 en la época de 1991 se arrastraba lentamente del Sol hacia otras plataformas y era relativamente crudo. El modelo de seguridad era esencialmente inexistente (la raíz en una máquina cliente podía leer el contenido completo de un montaje NFS) y el bloqueo, a través de nfs.lockd, era este lado de la experimentación. Habría sido una tontería esperar que la semántica de bandada funcione correctamente si es que existe entre dos implementaciones supuestamente interoperables diferentes. Coax era el PHY de Ethernet dominante en el momento en que muchos usuarios de la red nunca habían tenido el desagrado de usar (¿qué quiere decir que olvidó poner la resistencia de terminación de 50𝛀?) Si eso le da un mejor control del estado de las intranets.
Larry Wall y su equipo tenían todas las razones para hacer suposiciones pesimistas sobre la corrección de las cerraduras de NFS en ese momento, y este es el tipo de programación defensiva que los futuros codificadores no quieren eliminar porque es muy difícil demostrar la ausencia de un defecto. eliminar el código antiguo que se reintroduce en interoperabilidad con un sistema heredado del que nunca has oído hablar.
Desde entonces, NFS ha mejorado considerablemente y lockd ha migrado a tiempo a una característica del núcleo Linux 2.6. Para una colección de sistemas 2003+, es probable que se pueda confiar en el bloqueo de archivos NFS, especialmente si se prueba bien dentro de su aplicación en las muchas plataformas en las que se está ejecutando.
Todo lo anterior fue eliminado de la memoria, y probablemente podría confirmarse a través de la investigación (por ejemplo, http://nfs.sourceforge.net/ ), pero la prueba, como dicen, está en el bloqueo, y si no lo probó , se presume roto.
fuente
Otro, directamente de las preguntas frecuentes de Linux-NFS: nfs.sf.net
fuente
flock
no lo ha hecho, no lo hace y no se bloqueará en los montajes nfs.Esto está desactualizado ahora. NFS4 admite el bloqueo dentro del protocolo (no se requiere un demonio lockd o un mecanismo de devolución de llamada RPC) y el
flock()
método de Perl funciona bien: lo estamos usando en producción.Se implementaron versiones muy antiguas del kernel
flock
(syscall) como no operativas en NFS, y otras cosas como el bloqueo de rango de bytes no se admitían correctamente. De aquí viene la histeria.fuente