Tôi thiết lập máy chủ NFSv4 và máy khách đều chạy Debian 11.3 trên Linux 5.10.0-13. Về cơ bản, nó hoạt động tức là tôi thấy tất cả các tệp có quyền chính xác và có thể mở, sửa đổi, v.v. Tuy nhiên, việc mở tệp gây ra độ trễ 5 giây.
Máy chủ xuất các thư mục như thế này trong /etc/exports:
/path/to gss/krb5(rw,sync,fsid=0,crossmnt,no_subtree_check)
/path/to/NFS gss/krb5(rw,sync,no_subtree_check)
Xuất NFS4 được gắn bằng cách sử dụng loại này /etc/fstab lối vào:
máy chủ:/NFS /path/to/nfs nfs4 defaults,auto,sec=krb5,proto=tcp,port=2049,nolock 0 3
Dữ liệu sau đề cập đến việc mở một tệp trong emac và đóng lại emac ngay sau khi nó được hiển thị.
phân tích bước đi Tôi thấy rằng tương ứng mở () syscall mất 5,1 giây khá ổn định! Khác openat(), stat(), ... các tòa nhà chọc trời liên quan đến NFS thực thi trong vòng micro giây. Đây là những gì tôi thấy nhất quán khi thực hiện, ví dụ: ls, không cảm thấy khác với hệ thống tệp cục bộ. Đây là đoạn trích của cuộc gọi tòa nhà liên quan đến tệp được đề cập trước thời gian dành cho cuộc gọi tòa nhà:
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 (Đối số Das 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 (Đối số Das 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 ghi(14, "/path/to/nfs/file"..., 90) = 90
Trong Wireshark tôi thấy như sau:
STT Thời gian Nguồn đích Giao thức Chiều dài Thông tin
7 0.623097 client.ip server.ip Cuộc gọi NFS 276 V4 (Trả lời bằng 8) GETATTR FH: 0xecf8d891
8 0.624231 server.ip client.ip NFS 376 V4 Trả lời (Gọi trong 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 Cuộc gọi NFS 344 V4 (Trả lời trong 11) MỞ 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 Cuộc gọi NFS 340 V4 (Trả lời trong 14) ĐÓNG StateID: 0xb42f
14 5.743331 server.ip client.ip NFS 232 V4 Trả lời (Gọi vào 13) TRÌNH TỰ | Trạng thái 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
Tôi không biết liệu điều này NFS4ERR_STALE điều kiện là một gợi ý cho vấn đề. Theo RFC7530, nó chỉ ra rằng đối tượng hệ thống tệp đã bị xóa. Vâng, các tập tin trong bị trì hoãn mở () chắc chắn là không bị xóa. Vì vậy, tôi không chắc nó đề cập đến cái gì. Tuy nhiên, nó cũng cho thấy độ trễ 5,1 giây trong khoảng từ 12 đến 13.
Tôi phải thừa nhận rằng tôi không hoàn toàn hiểu những gì tôi thấy ở đây. Tuy nhiên, tôi cũng thấy tình trạng chậm trễ tương tự với các chương trình khác, tức là, đây không phải là điều khó hiểu. emac. Tiết kiệm trong thư viện thậm chí có thể đóng băng cho đến khi tệp được truy cập bởi một chương trình khác.
Vì tôi đã thấy ở đâu đó có vấn đề với krb5p trong một số môi trường, tôi giảm xuống krb5, nhưng điều này không thay đổi bất cứ điều gì.
Cả máy khách và máy chủ đều chạy gsproxy. Trên máy khách, tôi thấy các mục gỡ lỗi của nfsidmapvà sau khi thiết lập sysctl sunrpc.rpc_debug=0xFFFF Tôi thấy những điều sau đây cho emac kịch bản:
[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
Tôi không biết làm thế nào để giải thích chính xác nhật ký này, nhưng nó cũng hiển thị rõ ràng độ trễ 5 giây và đối với tôi, có vẻ như tất cả các lệnh gọi RPC đều được xử lý trong vòng 100 mili giây.
Bất kỳ ý tưởng những gì đang xảy ra, hoặc ít nhất là làm thế nào để tiếp tục giải quyết vấn đề?
