เหตุใดเซิร์ฟเวอร์ Linux NFS จึงถูกใช้งานในเคอร์เนลเมื่อเทียบกับ userspace

ฉันแค่สงสัยว่าเหตุใดเซิร์ฟเวอร์ Linux NFS จึงถูกนำไปใช้ในเคอร์เนลซึ่งตรงข้ามกับแอปพลิเคชัน userspace?

ฉันรู้ว่าdaemon ของ userspace NFSมีอยู่จริง แต่ไม่ใช่วิธีมาตรฐานสำหรับการให้บริการเซิร์ฟเวอร์ NFS

ฉันคิดว่าการใช้เซิร์ฟเวอร์ NFS เป็นแอปพลิเคชัน userspace จะเป็นวิธีการที่ต้องการเนื่องจากสามารถเพิ่มความปลอดภัยโดยให้ daemon ทำงานใน userspace แทนเคอร์เนล นอกจากนี้ยังสอดคล้องกับหลักการของ Linux ทั่วไปในการทำสิ่งหนึ่งและทำได้ดี (และ daemons นั้นไม่ควรทำงานกับเคอร์เนล)
ในความเป็นจริงประโยชน์เพียงอย่างเดียวที่ฉันสามารถคิดได้ในการทำงานของเคอร์เนลคือการเพิ่มประสิทธิภาพจากการสลับบริบท (และนั่นคือเหตุผลที่ถกเถียงกัน)

เหตุใดจึงมีการจัดทำเอกสารว่าทำไมจึงมีการนำไปปฏิบัติในทางที่เป็นอยู่? ฉันลอง googling ไปรอบ ๆ แต่หาอะไรไม่เจอ

unfs3ตายเท่าที่ฉันรู้ Ganeshaเป็นโครงการเซิร์ฟเวอร์ NFS userspace ที่ใช้งานมากที่สุดในขณะนี้แม้ว่ามันจะยังไม่โตเต็มที่ก็ตาม

แม้ว่าจะให้บริการโปรโตคอลที่แตกต่างกัน Samba เป็นตัวอย่างของไฟล์เซิร์ฟเวอร์ที่ประสบความสำเร็จที่ทำงานใน userspace

ฉันไม่เห็นการเปรียบเทียบประสิทธิภาพเมื่อเร็ว ๆ นี้

ปัญหาอื่น ๆ :

• แอ็พพลิเคชันทั่วไปค้นหาไฟล์โดยชื่อพา ธ แต่nfsdต้องสามารถค้นหาได้โดย filehandle นี่เป็นเรื่องยุ่งยากและต้องการการสนับสนุนจากระบบไฟล์ (และระบบไฟล์ทั้งหมดนั้นไม่สามารถรองรับได้) ในอดีตที่ผ่านมามันเป็นไปไม่ได้ที่จะทำสิ่งนี้จาก userspace แต่เมล็ดล่าสุดได้เพิ่ม name_to_handle_at(2)และopen_by_handle_at(2)สายระบบ
• ฉันดูเหมือนจะจำการบล็อกการโทรด้วยการล็อกไฟล์ว่าเป็นปัญหา ฉันไม่แน่ใจว่าเซิร์ฟเวอร์ userspace จัดการกับพวกเขาในวันนี้ได้อย่างไร (คุณผูกเธรดเซิร์ฟเวอร์ที่รอการล็อกหรือคุณโพลหรือไม่)
• ความหมายของระบบไฟล์ที่ใหม่กว่า (เปลี่ยนคุณลักษณะการมอบหมายการล็อคการแบ่งใช้) อาจถูกนำมาใช้อย่างง่ายดายในเคอร์เนลก่อน (ในทางทฤษฎี - พวกเขาส่วนใหญ่ยังไม่ได้รับ)
• คุณไม่ต้องการตรวจสอบสิทธิ์โควต้า ฯลฯ ด้วยมือ - แทนคุณต้องการเปลี่ยน uid ของคุณและใช้รหัส vfs ของเคอร์เนลทั่วไปเพื่อทำสิ่งนั้น และลีนุกซ์ก็มีสายระบบ ( setfsuid(2)) ที่ควรทำ ด้วยเหตุผลที่ฉันลืมฉันคิดว่ามันได้รับการพิสูจน์แล้วว่ามีความซับซ้อนในการใช้งานเซิร์ฟเวอร์มากกว่าที่ควรจะเป็น

โดยทั่วไปจุดแข็งของเคอร์เนลเซิร์ฟเวอร์คือการรวมกันอย่างใกล้ชิดกับ vfs และระบบไฟล์ที่ส่งออก เราสามารถทำสิ่งนั้นได้ด้วยการให้เคอร์เนลอินเทอร์เฟซมากขึ้น (เช่นการเรียกระบบ filehandle) แต่นั่นไม่ใช่เรื่องง่าย ในทางกลับกันบางระบบไฟล์ที่คนต้องการส่งออกวันนี้ (เช่น gluster) จริง ๆ แล้วส่วนใหญ่อยู่ใน userspace เคอร์เนล nfsd สามารถส่งออกได้โดยใช้ FUSE - แต่อาจต้องใช้ส่วนขยายอีกครั้งในอินเทอร์เฟซ FUSE สำหรับฟีเจอร์ที่ใหม่กว่าและอาจมีปัญหาด้านประสิทธิภาพ

รุ่นสั้น: คำถามที่ดี!

Olaf Kirch พัฒนาทั้งพื้นที่ผู้ใช้และเคอร์เนลเวอร์ชันพื้นฐานของเซิร์ฟเวอร์ NFS ในหนังสือปี 2000 ของเขา "Linux Network Administration" เขาพูดว่า:

เคอร์เนล 2.2.0 สนับสนุนเซิร์ฟเวอร์ NFS ที่ใช้เคอร์เนลรุ่นทดลองซึ่งพัฒนาโดย Olaf Kirch และพัฒนาเพิ่มเติมโดย HJ Lu, G. Allan Morris และ Trond Myklebust การสนับสนุน NFS ที่ใช้เคอร์เนลให้การสนับสนุนที่สำคัญในประสิทธิภาพของเซิร์ฟเวอร์

ฉันคิดว่าเมื่อเซิร์ฟเวอร์ NFS ถูกย้ายเข้าไปในเคอร์เนลเพื่อปรับปรุงประสิทธิภาพไม่มีใครเห็นเหตุผลที่จะนำมันออกมาอีกครั้ง

Starnamer นั้นถูกต้อง (ฉันเป็นหนึ่งในผู้ทดสอบเบต้า)

วางไว้ในเคอร์เนลเป็นความพยายามที่จะปรับปรุงประสิทธิภาพสุดซึ้ง (ส่วนใหญ่ให้กับลูกค้า PCNFS) และเมื่อปัญหาที่ได้รับการแก้ไขไม่มีใครมองมันอีกครั้ง

มีข้อบกพร่องหลายประการที่มี NFS ในเคอร์เนลซึ่งไม่น้อยไปกว่านี้คือมันไม่ได้เล่นอย่างดีกับสิ่งอื่นใดที่สัมผัสกับระบบไฟล์เดียวกัน ไม่ทราบว่ามันจะกลายเป็นปัญหา

เราอายุน้อยกว่าและโง่มากขึ้น ฯลฯ เป็นต้น