Básicamente tengo un servidor web para un sitio y otro que simplemente almacena archivos. El servidor de archivos se conecta al principal montando uno de sus directorios. El sitio web ejecuta Django, por lo que principalmente trato con python. De todos modos, parece que me he encontrado con algunos problemas con los archivos que se informan como no existentes incluso cuando realmente están allí.
Esencialmente cuando llamo
filepath = '/path/to/file/on/nfs/share' exists = os.path.exists(filepath)existe es falso a pesar de que el archivo realmente existe, y sé que existe porque tengo marcas de tiempo impresas en un archivo de registro que muestra exactamente cuándo se creó. No estoy seguro de cuál podría ser el problema, pero sé que los documentos para os.path.exists dicen
En algunas plataformas, esta función puede devolver False si no se otorga permiso para ejecutar os.stat() en el archivo solicitado, incluso si la ruta existe físicamente.
Sé que ese no es el caso porque ambos archivos comparten el mismo grupo y número de grupo, que también comparte los mismos números de grupo en ambos servidores. ¿Podría ser un caché obsoleto o algo así?
Mi montaje se realiza automáticamente a través de fstab.
Client side, the settings are: filehost:/filefolder /localfolder nfs defaults,rsize=32768,wsize=32768 Server side, the settings are: /filefolder webserver(rw,sync,no_root_squash,no_subtree_check)Editar:
Entonces, supongo que para obtener más información / detalles. Estoy ejecutando un subproceso de Python que genera un archivo en el directorio remoto. Cuando se realiza una solicitud, inicia el subproceso y devuelve la ubicación esperada del archivo.
En la interfaz, hay una URL a la que se le hace ping, donde llama a os.path.exists() para ese archivo y cuando lo hace, el recurso se carga a través de ajax.
El problema que se sospecha es que a veces este pinger informa que el archivo no está disponible durante unos segundos después de que realmente lo está. Esa es también la razón por la que pensé que tal vez era un posible problema con un caché obsoleto.
Todos los archivos y el directorio en ellos son propietario/grupo www-data, así como también cualquier subproceso que django esté instanciando. Además, este problema no parece ser completamente repetible. A veces funcionará rápidamente, mientras que otras tardará unos segundos más de lo esperado.
Esto se debe a la memoria caché NFS que se encuentra aquí :
El caché de atributos almacena todo en struct stat, por lo que las llamadas stat() y fstat() pueden devolverse desde el caché. Si necesita ver el último tamaño o mtime de un archivo (u otros campos), debe vaciar la caché de atributos del archivo antes de llamar a stat().
Tenga en cuenta que si el identificador de archivo está en caché, stat() devuelve información para ese archivo en caché (por lo que el resultado es el mismo que para fstat()). Si necesita stat() el archivo más reciente con el nombre de archivo dado, primero vacíe el caché del identificador de archivo.
Creo que su stat falla porque el archivo aún no está en el caché. Encontré esto en la página de manual de NFS:
ac / noac - Selects whether the client may cache file attributes. If neither option is specified (or if ac is specified), the client caches file attributes.
Pero también hay una advertencia allí, así que simplemente viví con la demora:
El uso de la opción noac proporciona una mayor coherencia de caché entre los clientes NFS que acceden a los mismos archivos, pero genera una penalización significativa en el rendimiento. Como tal, se alienta el uso juicioso del bloqueo de archivos. La sección COHERENCIA DE DATOS Y METADATOS contiene una discusión detallada de estas compensaciones.
mismo bicho! agregue una línea para resolver mi problema, tal vez debido a la memoria caché nfs
dir_name = "/path/to/file/on/nfs/share" # add this line os.system(f"ls -l {dir_name}") exists = os.path.exists(filepath)