แห่กัน (2) กับ fcntl (2) มากกว่า NFS

เอกสารประกอบของ Perl 5.x ระบุว่าการใช้งาน flock (.. ) จะใช้หนึ่งในการโทรแบบเนทีฟต่อไปนี้เริ่มต้นที่ 1 และทำงานไปที่ 3 หากไม่พร้อมใช้งาน:

1. แห่กัน (2)
2. fcntl (2)
3. lockf (3)

ไม่เป็นไร. อย่างไรก็ตามคุณอาจสังเกตเห็นข้อจำกัดความรับผิดชอบของพวกเขาว่าไม่ควรใช้ฝูง (2) ผ่าน NFS เอกสารแนะนำให้ใช้แฟล็ก -Ud_flock เพื่อบังคับให้ Perl ใช้ฝูง (2) หน้าคนของฝูง (2) (บน Redhat) ระบุข้อจำกัดความรับผิดชอบที่คล้ายกันเกี่ยวกับปัญหา NFS

คำถามของฉันคือทำไม!?!? ฉันไม่สามารถหาบทความเชิงลึกหรือคำอธิบายของ WHY flock (2) ที่ไม่ปลอดภัยผ่าน NFS

ฉันได้เขียนสคริปต์ทดสอบหลายชุดใน C และ Perl ทั้งบน Redhat (ที่มีการใช้ฝูง (2)) และใน Solaris (ที่มีการใช้ fcntl (2)) ฉันใช้ strace / truss เพื่อให้แน่ใจว่า Perl ใช้ flock (2) และ fcntl (2) ตามลำดับ ฉันไม่สามารถทำซ้ำปัญหาใด ๆ ที่ล็อคไม่ได้รับเกียรติ! สิ่งที่ช่วยให้??

Lennart Poettering เมื่อเร็ว ๆ นี้ได้ขุดลงไปในพฤติกรรมการล็อคระบบไฟล์ของ linux ซึ่งไม่ได้วาดรูปดอกกุหลาบโดยเฉพาะสำหรับล็อค NFS (โดยเฉพาะการติดตามที่เขาเชื่อมโยงไปที่ด้านล่างของโพสต์)

http://0pointer.de/blog/projects/locking.html

ฉันค่อนข้างแน่ใจว่าคุณกำลังมองหาข้อกังวลที่เป็นมรดก จำได้ว่าคู่มือ Perl5 เปิดตัวในปี 1994 และเป็นเพียงการแก้ไขคู่มือ Perl4 จากปี 1991 ในสมัยนั้นอาจกล่าวได้ว่าเกี่ยวกับระบบไฟล์ Nightmare ที่มีชื่อว่า "มันไม่ได้ดีขนาดไหน น่าประหลาดใจ แต่มันก็เต้น "

ยุค NFS2 ในปี 1991 ค่อยๆคลานออกจากดวงอาทิตย์ไปยังแพลตฟอร์มอื่น ๆ อย่างช้าๆและค่อนข้างหยาบ รูปแบบการรักษาความปลอดภัยนั้นไม่มีอยู่จริง (รูทบนเครื่องไคลเอนต์สามารถอ่านเนื้อหาทั้งหมดของการเมาท์ NFS) และการล็อค - ผ่าน nfs.lockd - เป็นด้านของการทดลองนี้ คุณคงโง่ที่จะคาดหวังว่าความหมายของฝูงจะทำงานได้อย่างถูกต้องหากมีการใช้งานร่วมกันที่ต่างกันสองแบบ Coax เป็น Ethernet PHY ที่โดดเด่นในขณะที่ผู้ใช้เครือข่ายจำนวนมากไม่เคยมีความไม่พอใจในการใช้งาน (คุณหมายความว่าคุณลืมใส่ตัวต้านทานการเลิกจ้าง 50𝛀 หรือไม่?) ถ้ามันช่วยให้คุณจับอินทราเน็ตได้ดีขึ้น

ลาร์รีวอลล์และทีมงานมีเหตุผลทุกประการที่จะทำให้สมมติฐานในแง่ร้ายเกี่ยวกับความถูกต้องของ NFS ล็อคในเวลานั้นและนี่คือการเขียนโปรแกรมป้องกันแบบที่นักจ๊อกกี้โค้ดในอนาคตเกลียดที่จะลบเพราะมันยากที่จะพิสูจน์ว่า การลบรหัสเก่าซึ่งถูกนำมาใช้ใหม่ในการทำงานร่วมกันกับระบบเดิมที่คุณไม่เคยได้ยินมาก่อน

ตั้งแต่นั้นมา NFS ได้รับการปรับปรุงอย่างมากและ lockd ได้ย้ายข้อมูลไปยังคุณลักษณะของเคอร์เนล Linux 2.6 ได้ทันเวลา สำหรับคอลเลกชันของระบบ 2003+ การล็อคไฟล์ NFS อาจเชื่อถือได้โดยเฉพาะถ้าทดสอบได้ดีในแอปพลิเคชันของคุณในหลาย ๆ แพลตฟอร์มที่อาจทำงานอยู่

ทั้งหมดที่กล่าวมาข้างต้นถูก cribbed จากหน่วยความจำและมีแนวโน้มที่จะพิสูจน์ได้จากการวิจัย (เช่นhttp://nfs.sourceforge.net/ ) แต่การพิสูจน์ - ตามที่พวกเขาบอกว่า - อยู่ในการล็อคและหากคุณไม่ได้ทดสอบ มันจะสันนิษฐานว่าแตก

อีกอันหนึ่งตรงจาก Linux-NFS คำถามที่พบบ่อย: nfs.sf.net

ฉันกำลังพยายามใช้การล็อก flock () / BSD เพื่อล็อคไฟล์ที่ใช้กับไคลเอนต์หลายตัว แต่ไฟล์เสียหาย มาทำไม A. flock () / BSD ล็อคทำหน้าที่เฉพาะบนไคลเอนต์ Linux NFS ก่อน 2.6.12 ใช้การล็อค fcntl () / POSIX เพื่อให้แน่ใจว่าการล็อคไฟล์จะปรากฏให้ลูกค้ารายอื่นเห็นได้

ต่อไปนี้เป็นวิธีการเข้าถึงไฟล์ NFS เป็นลำดับ

ใช้ API การล็อค fcntl () / POSIX การล็อกชนิดนี้จัดเตรียมการล็อกช่วงไบต์สำหรับไคลเอ็นต์หลายตัวผ่านโปรโตคอล NLM หรือผ่าน NFSv4 ใช้ lockfile แยกต่างหากและสร้างฮาร์ดลิงก์ไปยังมัน ดูคำอธิบายในส่วน O_EXCL ของหน้า creat (2) เป็นที่น่าสังเกตว่าจนกระทั่งต้น 2.6 เมล็ด O_EXCL สร้างไม่ได้เป็นอะตอมมิกบนไคลเอนต์ Linux NFS อย่าใช้ O_EXCL สร้างและคาดหวังว่าพฤติกรรมแบบปรมาณูระหว่างไคลเอนต์ NFS หลายรายการยกเว้นว่าคุณใช้เคอร์เนลใหม่กว่า 2.6.5

เป็นปัญหาที่ทราบกันดีว่า Perl ใช้การล็อค flock () / BSD เป็นค่าเริ่มต้น สิ่งนี้สามารถทำลายโปรแกรมที่พอร์ตจากระบบปฏิบัติการอื่นเช่น Solaris ซึ่งคาดว่าการล็อก flock / BSD จะทำงานเหมือนล็อค POSIX

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

ไคลเอ็นต์ NFS ใน 2.6.12 ให้การสนับสนุนสำหรับการล็อก flock () / BSD บนไฟล์ NFS โดยจำลองการล็อกสไตล์ BSD ในแง่ของการล็อคช่วงไบต์ POSIX ไคลเอนต์ NFS อื่น ๆ ที่ใช้กลไกการจำลองแบบเดียวกันหรือที่ใช้การล็อค fcntl () / POSIX จะเห็นการล็อกเดียวกันกับที่ไคลเอ็นต์ Linux NFS เห็น

บนระบบไฟล์โลคัล Linux, POSIX ล็อคและล็อค BSD จะมองไม่เห็นซึ่งกันและกัน ดังนั้นเนื่องจากการจำลองนี้แอปพลิเคชันที่ทำงานบนเซิร์ฟเวอร์ Linux NFS จะยังคงเห็นไฟล์ที่ถูกล็อกโดยไคลเอนต์ NFS ว่าถูกล็อกด้วยการล็อค fcntl () / POSIX ไม่ว่าแอปพลิเคชันบนไคลเอนต์จะใช้สไตล์ BSD หรือ POSIX- ล็อคสไตล์ หากแอปพลิเคชันเซิร์ฟเวอร์ใช้การล็อค flock () BSD จะไม่เห็นการล็อคที่ไคลเอ็นต์ NFS ใช้

นี่ล้าสมัยแล้ว NFS4 รองรับการล็อกภายในโปรโตคอล (ไม่จำเป็นต้องใช้ lockd daemon หรือกลไกการเรียกกลับ RPC) และflock()วิธีการของ Perl ทำงานได้ดี - เราใช้มันในการผลิต

เคอร์เนลเวอร์ชันเก่ามากนำมาใช้flock(syscall) เป็นแบบไม่มี op-on NFS และสิ่งอื่น ๆ เช่นการล็อกช่วงไบต์ไม่ได้รับการสนับสนุนอย่างเหมาะสม นี่คือที่ฮิสทีเรียมาจาก