Tại sao máy chủ Linux NFS được triển khai trong kernel trái ngược với không gian người dùng?


33

Tôi chỉ tự hỏi tại sao máy chủ Linux NFS được triển khai trong kernel trái ngược với ứng dụng không gian người dùng?

Tôi biết một daemon NFS không gian người dùng tồn tại, nhưng đó không phải là phương pháp tiêu chuẩn để cung cấp dịch vụ máy chủ NFS.

Tôi nghĩ rằng việc chạy máy chủ NFS như một ứng dụng không gian người dùng sẽ là cách tiếp cận ưa thích vì nó có thể cung cấp bảo mật bổ sung có một daemon chạy trong không gian người dùng thay vì kernel. Nó cũng sẽ phù hợp với hiệu trưởng Linux thông thường là làm một việc và làm tốt việc đó (và daemon không nên là một công việc cho kernel).
Trong thực tế, lợi ích duy nhất tôi có thể nghĩ đến khi chạy trong kernel sẽ tăng hiệu năng từ chuyển đổi ngữ cảnh (và đó là một lý do gây tranh cãi).

Vì vậy, có bất kỳ lý do tài liệu tại sao nó được thực hiện theo cách đó? Tôi đã cố gắng googling xung quanh nhưng không thể tìm thấy bất cứ điều gì.


Dường như có rất nhiều nhầm lẫn, xin lưu ý tôi không hỏi về việc gắn hệ thống tập tin, tôi đang hỏi về việc cung cấp phía máy chủ của hệ thống tập tin mạng . Có một sự khác biệt rất rõ ràng. Gắn kết một hệ thống tệp cục bộ yêu cầu hỗ trợ cho hệ thống tệp trong kernel, miễn là nó không (ví dụ: samba hoặc unls3).


NFS là một hệ thống tập tin. Trình điều khiển hệ thống tập tin người dùng phải sử dụng FUSE, thường kém về hiệu năng.
jordanm

@jordanm không họ không. Trong thực tế, bạn không thể chạy các hệ thống tệp mạng (NFS, CIFS / samba, coda, v.v.) thông qua FUSE. FUSE có nghĩa là để gắn các hệ thống tập tin trên máy cục bộ, không phục vụ chúng.
Patrick

bạn nói đúng, tuyên bố của tôi sẽ chỉ áp dụng cho khách hàng.
jordanm

@jordanm thậm chí không may. Bạn có thể gắn hệ thống tập tin mà không cần FUSE. FUSE dù sao cũng là một công nghệ tương đối mới, phía máy khách của các hệ thống tệp mạng đã tồn tại từ lâu trước khi FUSE thực hiện :-). FUSE chỉ cung cấp một cách để hỗ trợ các hệ thống tập tin không được cung cấp bởi kernel (không cố gắng có ý nghĩa, chỉ hy vọng làm sáng tỏ những quan niệm sai lầm :-P)
Patrick

2
@StarNamer bạn vẫn đang nói về khách hàng. Tôi đang nói về máy chủ. Bạn có thể chạy unfs3(là máy chủ NFS) mà không cần bất kỳ hỗ trợ kernel nào cho nó.
Patrick

Câu trả lời:


25

unfs3đã chết theo như tôi biết; Ganesha là dự án máy chủ NFS không gian người dùng tích cực nhất hiện nay, mặc dù nó chưa hoàn toàn trưởng thành.

Mặc dù nó phục vụ các giao thức khác nhau, Samba là một ví dụ về một máy chủ tệp thành công hoạt động trong không gian người dùng.

Tôi chưa thấy một so sánh hiệu suất gần đây.

Một số vấn đề khác:

  • Các ứng dụng thông thường tìm tệp theo tên đường dẫn, nhưng nfsdcần có thể tra cứu chúng bằng filehandle. Điều này là khó khăn và yêu cầu hỗ trợ từ hệ thống tập tin (và không phải tất cả các hệ thống tập tin có thể hỗ trợ nó). Trước đây, không thể thực hiện điều này từ không gian người dùng, nhưng các hạt nhân gần đây đã thêm name_to_handle_at(2)open_by_handle_at(2)gọi hệ thống.
  • Tôi dường như nhớ lại việc chặn các cuộc gọi khóa tập tin là một vấn đề; Tôi không chắc chắn làm thế nào các máy chủ không gian người dùng xử lý chúng những ngày này. (Bạn có buộc một chuỗi máy chủ đang chờ trên khóa không, hoặc bạn có thăm dò ý kiến ​​không?)
  • Ngữ nghĩa hệ thống tệp mới hơn (thay đổi thuộc tính, ủy nhiệm, khóa chia sẻ) có thể được triển khai dễ dàng hơn trong kernel trước (về lý thuyết - chúng hầu như chưa có).
  • Bạn không muốn phải kiểm tra quyền, hạn ngạch, v.v., bằng tay - thay vào đó bạn muốn thay đổi uid của mình và dựa vào mã vfs kernel phổ biến để làm điều đó. Và Linux có một cuộc gọi hệ thống ( setfsuid(2)) nên làm điều đó. Vì những lý do tôi quên, tôi nghĩ rằng việc sử dụng máy chủ trở nên phức tạp hơn so với thực tế.

Nói chung, điểm mạnh của máy chủ kernel là tích hợp chặt chẽ hơn với vfs và hệ thống tệp được xuất. Chúng tôi có thể bù đắp cho điều đó bằng cách cung cấp nhiều giao diện kernel hơn (như các cuộc gọi hệ thống tập tin), nhưng điều đó không dễ dàng. Mặt khác, một số hệ thống tập tin mà mọi người muốn xuất ngày nay (như ánh sáng) thực sự sống chủ yếu trong không gian người dùng. Chúng có thể được xuất ra bởi kernel nfsd bằng FUSE - nhưng một lần nữa các phần mở rộng cho giao diện FUSE có thể được yêu cầu cho các tính năng mới hơn và có thể có vấn đề về hiệu năng.

Phiên bản ngắn: câu hỏi hay!


2
Bạn đọc nên lưu ý rằng Bruce là (a? The?) Của máy chủ linux NFS, vì vậy có lẽ anh ta biết mình đang nói về cái gì. :)
Dan Pritts

@derfian FYI - bạn có thể muốn bình luận ở đây về hiệu ứng " unfs3còn sống và chuyển sang Github" không?
ms-ati

Tôi đã nhận xét ở trên vì @derfian hoặc người dùng StackOverflow ( unix.stackexchange.com/users/23034/derfian ), là người duy trì của unss3, và gần đây đã thông báo rằng nó không chết, ví dụ như trong bình luận Github này
ms-ati

Đối với một người duy trì NFS viết, câu trả lời này khá mơ hồ.
Torsten Bronger

18

Olaf Kirch ban đầu đã phát triển cả phiên bản dựa trên không gian người dùng và kernel của máy chủ NFS. Trong cuốn sách năm 2000 của mình, "Quản trị mạng Linux", ông nói:

Hạt nhân 2.2.0 hỗ trợ máy chủ NFS dựa trên hạt nhân thử nghiệm được phát triển bởi Olaf Kirch và được phát triển thêm bởi HJ Lu, G. Allan Morris và Trond Myklebust. Hỗ trợ NFS dựa trên kernel cung cấp hiệu suất máy chủ tăng đáng kể.

Tôi nghĩ rằng một khi máy chủ NFS đã được chuyển vào kernel để cải thiện hiệu năng, không ai thấy bất kỳ lý do nào để đưa nó ra ngoài một lần nữa.


8

Starnamer là chính xác (Tôi là một trong những người thử nghiệm beta).

Đưa nó vào kernel là một nỗ lực để cải thiện hiệu năng hoạt động (chủ yếu cho các máy khách PCNFS) và một khi vấn đề đó được giải quyết, không ai nhìn lại nó nhiều lần nữa.

Có một số thiếu sót khi có NFS trong kernel, trong đó ít nhất là nó không chơi tốt với bất kỳ thứ gì khác chạm vào cùng một hệ thống tập tin (có những rủi ro tham nhũng khó chịu nghiêm trọng) nhưng trước đó (1993-4) chúng tôi đã không Tôi nhận ra rằng nó sẽ trở thành một vấn đề.

Chúng tôi trẻ hơn và ngốc nghếch hơn, v.v.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.