Configuré un servidor NFSv4 y un cliente, ambos ejecutando Debian 11.3 en Linux 5.10.0-13. Básicamente funciona, es decir, veo todos los archivos con los permisos correctos y puedo abrirlos, modificarlos, etc. Sin embargo, abrir un archivo provoca un retraso de 5 segundos.
El servidor exporta directorios como este en /etc/exports:
/path/to gss/krb5(rw,sync,fsid=0,crossmnt,no_subtree_check)
/path/to/NFS gss/krb5(rw,sync,no_subtree_check)
La exportación NFS4 se monta utilizando este tipo de /etc/fstabentrada:
server:/NFS /path/to/nfs nfs4 defaults,auto,sec=krb5,proto=tcp,port=2049,nolock 0 3
Los siguientes datos se refieren a abrir un archivo emacsy cerrarlo emacstan pronto como se muestra.
Analizando straceveo que la openat()llamada al sistema correspondiente tarda 5,1 segundos bastante estables. Otras openat(), stat(), ...llamadas al sistema pertenecientes a NFS se ejecutan en microsegundos. Esto es lo que veo constantemente cuando hago, por ejemplo, ls, que no se siente diferente del sistema de archivos local. Este es un extracto de llamadas al sistema relacionadas con el archivo en cuestión precedidas por el tiempo transcurrido en la llamada al sistema:
0.000014 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Ist kein Verzeichnis)
0.000005 readlinkat(AT_FDCWD, "/path/to/nfs/file", 0x7fff202f6880, 1024) = -1 EINVAL (Das Argument ist ungültig)
0.000006 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 14
0.000005 readlinkat(AT_FDCWD, "/path/to/nfs/file", 0x7fff202f64d0, 1024) = -1 EINVAL (Das Argument ist ungültig)
0.000005 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 14
5.108682 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC) = 14
0.000006 faccessat(AT_FDCWD, "/path/to/nfs/file", W_OK) = 0
0.000005 stat("/path/to/nfs/file", {st_mode=S_IFREG|0640, st_size=2192, ...}) = 0
0.000007 faccessat(AT_FDCWD, "/path/to/nfs/file,v", F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
0.000009 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Ist kein Verzeichnis)
0.000008 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Ist kein Verzeichnis)
0.000008 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Ist kein Verzeichnis)
0.000008 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Ist kein Verzeichnis)
0.000008 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Ist kein Verzeichnis)
0.000012 stat("/path/to/nfs/file", {st_mode=S_IFREG|0640, st_size=2192, ...}) = 0
0.000015 write(14, "/path/to/nfs/file"..., 90) = 90
En Wirehark veo lo siguiente:
No. Time Source Destination Protocol Length Info
7 0.623097 client.ip server.ip NFS 276 V4 Call (Reply In 8) GETATTR FH: 0xecf8d891
8 0.624231 server.ip client.ip NFS 376 V4 Reply (Call In 7) GETATTR
9 0.624239 client.ip server.ip TCP 72 951 → 2049 [ACK] Seq=601 Ack=917 Win=4176 Len=0 TSval=1071244404 TSecr=3950562910
10 0.624696 client.ip server.ip NFS 344 V4 Call (Reply In 11) OPEN DH: 0xecf8d891/
11 0.625669 server.ip client.ip NFS 452 V4 Reply (Call In 10) OPEN StateID: 0xb42f
12 0.625693 client.ip server.ip TCP 72 951 → 2049 [ACK] Seq=873 Ack=1297 Win=4176 Len=0 TSval=1071244405 TSecr=3950562911
13 5.742166 client.ip server.ip NFS 340 V4 Call (Reply In 14) CLOSE StateID: 0xb42f
14 5.743331 server.ip client.ip NFS 232 V4 Reply (Call In 13) SEQUENCE | PUTFH Status: NFS4ERR_STALE
15 5.743359 client.ip server.ip TCP 72 951 → 2049 [ACK] Seq=1141 Ack=1457 Win=4176 Len=0 TSval=1071249523 TSecr=3950568029
No sé si esta NFS4ERR_STALEcondición es un indicio del problema. Según RFC7530, indica que el objeto del sistema de archivos ha sido eliminado. Bueno, el archivo retrasado openat()definitivamente no se elimina. Así que no estoy seguro a qué se refiere. Sin embargo, también muestra el retraso de 5,1 segundos entre las 12 y las 13.
Debo admitir que no entiendo muy bien lo que veo aquí. Sin embargo, también veo el mismo tipo de retrasos en otros programas, es decir, esto no es una rareza emacs. Guardar libreofficepuede incluso congelarse hasta que otro programa acceda al archivo.
Como vi en alguna parte que hay problemas krb5pen algunos entornos, lo reduje a krb5, pero esto no cambió nada.
Tanto el cliente como el servidor se ejecutan gssproxy. En el cliente veo entradas de depuración de nfsidmapy después de configurar sysctl sunrpc.rpc_debug=0xFFFFveo lo siguiente para el emacsescenario:
[423544.865600] RPC: gss_get_mic_v2
[423544.865628] RPC: xs_tcp_send_request(200) = 0
[423544.867049] RPC: xs_data_ready...
[423544.867309] RPC: gss_verify_mic_v2
[423545.373665] RPC: gss_get_mic_v2
[423545.373691] RPC: xs_tcp_send_request(200) = 0
[423545.374692] RPC: xs_data_ready...
[423545.374748] RPC: gss_verify_mic_v2
[423545.375009] RPC: gss_get_mic_v2
[423545.375025] RPC: xs_tcp_send_request(268) = 0
[423545.375909] RPC: xs_data_ready...
[423545.375957] RPC: gss_verify_mic_v2
[423550.467227] RPC: gss_get_mic_v2
[423550.467307] RPC: xs_tcp_send_request(216) = 0
[423550.468395] RPC: xs_data_ready...
[423550.468513] RPC: gss_verify_mic_v2
[423550.468621] RPC: gss_get_mic_v2
[423550.468646] RPC: gss_get_mic_v2
[423550.468689] RPC: xs_tcp_send_request(264) = 0
[423550.469403] RPC: xs_data_ready...
[423550.469541] RPC: gss_verify_mic_v2
[423550.469564] RPC: gss_verify_mic_v2
[423550.472794] RPC: gss_get_mic_v2
[423550.472849] RPC: xs_tcp_send_request(208) = 0
[423550.473758] RPC: xs_data_ready...
[423550.473903] RPC: gss_verify_mic_v2
[423550.474234] RPC: gss_get_mic_v2
[423550.474290] RPC: xs_tcp_send_request(200) = 0
[423550.475147] RPC: xs_data_ready...
[423550.475257] RPC: gss_verify_mic_v2
No tengo idea de cómo interpretar exactamente este registro, pero también muestra claramente el retraso de 5 segundos y me parece que todas las llamadas RPC se procesan en 100 ms.
¿Alguna idea de lo que está pasando o al menos de cómo precisar más el problema?
Respuesta1
Resolví el problema cuando la VPN de mi segundo sitio falló hace algún tiempo. El servidor esclavo Kerberos utilizado por el servidor NFS tenía su servidor DNS apuntando al otro sitio, es decir, a través de una VPN lenta. Todavía es desconcertante ya que la VPN no es tan lenta y no vi retrasos de 5 segundos, por ejemplo, durante el inicio de sesión, pero después de cambiar el DNS al esclavo local el problema desapareció.
Mientras tanto, instalé el nuevo servidor y funciona sin problemas.