Am configurat un server NFSv4 și un client care rulează ambele Debian 11.3 pe Linux 5.10.0-13. Practic, funcționează, adică văd toate fișierele cu permisiunile corecte și pot deschide, modifica etc. Cu toate acestea, deschiderea unui fișier provoacă o întârziere de 5 secunde.
Serverul exportă directoare ca acesta în /etc/exports:
/cale/la gss/krb5(rw,sync,fsid=0,crossmnt,no_subtree_check)
/path/to/NFS gss/krb5(rw,sync,no_subtree_check)
Exportul NFS4 este montat folosind acest tip de /etc/fstab intrare:
server:/NFS /path/to/nfs nfs4 defaults,auto,sec=krb5,proto=tcp,port=2049,nolock 0 3
Următoarele date se referă la deschiderea unui fișier în emacs și aproape emacs de îndată ce este afișat.
Analizand strace Văd că corespunzătoare deschide() syscall durează destul de stabil 5,1 secunde! Alte openat(), stat(),... Apelurile de sistem referitoare la NFS se execută în microsecunde. Aceasta este ceea ce văd în mod constant când fac de ex. ls, care nu se simte diferit de sistemul de fișiere local. Acesta este un extras al apelurilor de sistem legate de fișierul în cauză, precedat de timpul petrecut în apelul de sistem:
0.000014 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Primul versant)
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 (Prima versiune)
0.000008 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Primul versant)
0.000008 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Primul versant)
0.000008 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Primul versant)
0.000008 openat(AT_FDCWD, "/path/to/nfs/file", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Primul versant)
0.000012 stat("/path/to/nfs/file", {st_mode=S_IFREG|0640, st_size=2192, ...}) = 0
0,000015 scrie (14, "/cale/la/nfs/fișier"..., 90) = 90
În wireshark văd următoarele:
Nr. Ora Sursă Destinație Protocol Lungime Informații
7 0.623097 client.ip server.ip NFS 276 V4 Apel (Răspuns în 8) GETATTR FH: 0xecf8d891
8 0.624231 server.ip client.ip NFS 376 V4 Răspuns (Apel 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 Apel (Răspuns în 11) DESCHIS DH: 0xecf8d891/
11 0.625669 server.ip client.ip NFS 452 V4 Răspuns (Apel 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 Apel NFS 340 V4 (Răspuns în 14) CLOSE StateID: 0xb42f
14 5.743331 server.ip client.ip NFS 232 V4 Răspuns (Call In 13) SECVENȚĂ | Stare PUTFH: 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
Nu stiu daca asta NFS4ERR_STALE starea este un indiciu al problemei. Conform RFC7530, acesta indică faptul că obiectul sistemului de fișiere a fost eliminat. Ei bine, dosarul este întârziat deschide() cu siguranta nu este sters. Deci, nu sunt sigur la ce se referă. Cu toate acestea, arată și întârzierea de 5,1 secunde între 12 și 13.
Trebuie să recunosc că nu prea înțeleg ce văd aici. Cu toate acestea, văd același tip de întârzieri și cu alte programe, adică nu este o ciudatenie. emacs. Economisire în libreoffice poate chiar să înghețe până când fișierul este accesat de un alt program.
De când am văzut undeva că sunt probleme cu krb5p în unele medii, m-am redus la krb5, dar asta nu a schimbat nimic.
Atat clientul cat si serverul ruleaza gssproxy. Pe client văd intrări de depanare ale nfsidmap, iar după setare sysctl sunrpc.rpc_debug=0xFFFF Văd următoarele pentru emacs scenariu:
[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
Nu am idee cum să interpretez exact acest jurnal, dar arată clar și întârzierea de 5 secunde și mi se pare că toate apelurile RPC sunt procesate în 100 ms.
Aveți idee despre ce se întâmplă, sau cel puțin cum să clarificați în continuare problema?
