Accesos muy lentos a archivos en red con Gnome

Posted on by

O dicho de otra forma, vaya faena. Porque los usuarios lo que quieren, los pobres, es abrir rápidamente sus carpetas y buscar, arriba y abajo, el archivo que necesitan.

Y si el programa que manipula archivos se queda colgado de manera aleatoria, un ratito a veces, un muchillón de segundos otra, no avanzamos. Y se quejan porque sufren y yo les atiendo porque no tengo otra.

Lo curioso del caso es que he podido reproducir lo que ocurre en mi propia máquina y a la primera. No me había dado cuenta de que tenía esos problemas porque empleo sobre todo el terminal pero me ha tocado también.

El escenario es el siguiente. Tenemos un directorio de archivos compartidos (documentos sobre todo) al que acceden las máquinas Windows vía Samba y que no ha dado problemas hasta ahora. Cuando todos los terminales eran Linux yo empleaba el automontaje vía NFS y tampoco los tenía. Tuve que hacer varios ajustes al principio pero luego ha ido de maravilla.

Ahora, cuando voy recuperando los Linux poco a poco he seguido el mismo sistema pero en lugar de montar por NFS monto por CIFS. Y tampoco tengo problemas en este sentido hasta que aparece Gnome en escena (versión de Debian 11) y su caché de archivos en el subsistema gvfs (Gnome Virtual File System) gestionado por un programa llamado gvfsd-metadata que es un auténtico dolor y el causante de todo el problema. Si tienes activo los servicios Gnome cualquier gestor de archivos que utilices (Nautilus, Caja, Thunar, …) lo emplean y el sistema pasa a sufrir parones sin sentido en cualquier momento y lugar. Generalmente los momentos elegidos son certeros: cuando el homínido quiere abrir un archivo.

Al principio pensaba que sería cosa del montaje CIFS, que tiene un zillón de opciones que corresponden a la absurda complejidad de los protocolos Microsoft, pero he estado haciendo pruebas con listados directos (programa ls) y listados más trabajados (programa mc) y nada. Va de maravilla en todo momento.

He buscado en la red si había algún error y sí, encuentras un montón de entradas, pero todas terminan repitiendo el mantra de que para solucionarlo hay que borrar el caché local (rm ~/.local/share/gvfs-metadata), eliminar el proceso (pkill gvfsd-metadata) y/o desactivar el servicio (systemctl –user mask gvfs-metadata.service), según les dé la ventolera.

Y, claro, a nivel de operador homínido ninguna de esas soluciones tiene sentido alguno. La última, la desactivación, hace que todo el sistema gvfs se cuelgue y no funcione. Las otras dos consiguen algo parecido con el agravante de que el servicio vuelve a la vida sin datos y se pone concienzudo en la recuperación. Nada, que no valen un pimiento.

Quizás sea la diferencia de versiones entre los clientes y el servidor. Los primeros son Debian 11 y el último sigue siendo un Debian 10, pero yo creo que no van por ahí los tiros. Creo que el problema (aunque no estoy seguro) es que la carpeta de archivos compartidos contiene más de 90.000 ficheros y directorios y que en algún momento a alguno de los gestores de ficheros le da por mirar en profundidad y el caché se satura de trabajo. El cómo y el cuándo son incógnitas de momento. Lo que ahora quiero es ver si dicho programa (gvfsd-metada) tiene alguna manera de limitar lo que hace. Quizás, al ser montajes locales, no lo considera sistemas de archivos remotos y los trata de forma normal y, claro, se lía.

Enlaces y referencias