flock (2) versus fcntl (2) melalui NFS

Dokumentasi Perl 5.x menyatakan bahwa penerapan kawanan (..) akan menggunakan salah satu dari panggilan asli berikut, mulai dari 1 dan bekerja menuju 3 jika tidak tersedia:

1. flock (2)
2. fcntl (2)
3. lockf (3)

Tidak apa-apa. Namun, Anda mungkin telah memperhatikan penafian mereka bahwa kawanan (2) tidak boleh digunakan di atas NFS. Doc menyarankan menggunakan flag -Ud_flock untuk memaksa Perl menggunakan flock (2). Halaman manual dari flock (2) (di Redhat) menyatakan penafian yang sama tentang masalah NFS.

Pertanyaan saya adalah, mengapa!?!? Sepertinya saya tidak dapat menemukan artikel yang mendalam atau penjelasan tentang MENGAPA kawanan (2) tidak aman untuk NFS.

Saya telah menulis beberapa skrip uji dalam C dan Perl, di Redhat (di mana kawanan (2) digunakan) dan di Solaris (di mana fcntl (2) digunakan). Saya berlari strace / truss untuk memastikan bahwa Perl memang menggunakan kawanan (2) dan fcntl (2) masing-masing. Saya tidak bisa meniru masalah apa pun di mana kunci tidak dihormati! Apa yang memberi ??

Lennart Poettering baru-baru ini melakukan beberapa penggalian ke dalam perilaku penguncian sistem file linux, yang tidak melukiskan gambar yang sangat indah untuk mengunci NFS (terutama tindak lanjut yang ia tautkan di bagian bawah posting).

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

Saya cukup yakin bahwa Anda melihat masalah warisan. Ingatlah bahwa manual Perl5 dirilis pada tahun 1994 dan itu hanya merupakan pengeditan manual Perl4 dari tahun 1991. Pada masa itu mungkin dapat dikatakan tentang Nightmare File System yang sering disebut bahwa "tidak sebaik tarian beruang yang heran, tapi itu menari sama sekali ".

NFS2 pada zaman 1991 perlahan-lahan merangkak keluar dari Sun ke platform lain dan relatif kasar. Model keamanan pada dasarnya tidak ada (root pada mesin klien dapat membaca isi lengkap dari mount NFS) dan penguncian - melalui nfs.lockd - adalah sisi eksperimental ini. Anda akan bodoh untuk mengharapkan semantik kawanan berfungsi dengan baik jika sama sekali antara dua implementasi yang diduga saling beroperasi. Coax adalah Ethernet PHY yang dominan pada saat itu yang banyak pengguna jaringan tidak pernah merasa tidak senang menggunakan (apa maksud Anda Anda lupa meletakkan resistor terminasi 50𝛀?) Jika itu memberi Anda cengkeraman yang lebih baik pada keadaan intranet.

Larry Wall dan kru memiliki setiap alasan untuk membuat asumsi pesimistis tentang kebenaran kunci NFS pada saat itu, dan ini adalah jenis pemrograman defensif yang oleh joki kode masa depan enggan untuk dihapus karena begitu sulit untuk membuktikan tidak adanya cacat oleh menghapus kode lama yang diperkenalkan kembali dalam interoperabilitas dengan sistem lama yang bahkan tidak pernah Anda dengar sebelumnya.

Sejak itu, NFS telah meningkat pesat, dan lockd telah bermigrasi tepat waktu ke fitur kernel Linux 2.6. Untuk koleksi sistem 2003+, penguncian file NFS mungkin dapat dipercaya, terutama jika diuji dengan baik di dalam aplikasi Anda di banyak platform yang sedang berjalan.

Semua hal di atas diambil dari memori, dan kemungkinan dapat dibuktikan melalui penelitian (mis. Http://nfs.sourceforge.net/ ) tetapi buktinya - seperti kata mereka - ada di penguncian, dan jika Anda tidak mengujinya , itu dianggap rusak.

Satu lagi, langsung dari FAQ Linux-NFS: nfs.sf.net

Saya mencoba menggunakan kunci flock () / BSD untuk mengunci file yang digunakan pada banyak klien, tetapi file menjadi rusak. Bagaimana bisa? A. flock () / kunci BSD hanya bertindak secara lokal pada klien Linux NFS sebelum 2.6.12. Gunakan kunci fcntl () / POSIX untuk memastikan bahwa kunci file dapat dilihat oleh klien lain.

Berikut adalah beberapa cara untuk membuat serialisasi akses ke file NFS.

Gunakan API pengunci fcntl () / POSIX. Jenis penguncian ini menyediakan penguncian rentang-byte di banyak klien melalui protokol NLM, atau melalui NFSv4. Gunakan file kunci terpisah, dan buat tautan keras ke sana. Lihat deskripsi di bagian O_EXCL halaman manual creat (2). Perlu dicatat bahwa sampai kernel 2.6 awal, O_EXCL menciptakan tidak atom pada klien Linux NFS. Jangan gunakan O_EXCL membuat dan mengharapkan perilaku atom di antara banyak klien NFS kecuali Anda menjalankan kernel yang lebih baru dari 2.6.5.

Ini masalah yang diketahui Perl menggunakan penguncian kawanan () / BSD secara default. Ini dapat memecah program yang porting dari sistem operasi lain, seperti Solaris, yang mengharapkan kunci kawanan / BSD berfungsi seperti kunci POSIX.

Di Linux, menggunakan penguncian file sebagai ganti tautan keras memiliki manfaat tambahan dengan memeriksa titik cache klien dengan server. Ketika kunci file diperoleh, klien akan membuka cache halaman untuk file itu sehingga setiap pembacaan selanjutnya mendapatkan data baru dari server. Ketika kunci file dilepaskan, setiap perubahan pada file pada klien itu dibilas kembali ke server sebelum kunci dilepaskan sehingga klien lain yang menunggu untuk mengunci file itu dapat melihat perubahan.

Klien NFS di 2.6.12 menyediakan dukungan untuk kawanan () / kunci BSD pada file NFS dengan meniru kunci gaya BSD dalam hal kunci jangkauan byte POSIX. Klien NFS lain yang menggunakan mekanisme emulasi yang sama, atau yang menggunakan kunci fcntl () / POSIX, kemudian akan melihat kunci yang sama dengan yang dilihat oleh klien Linux NFS.

Pada sistem file Linux lokal, kunci POSIX dan kunci BSD tidak terlihat satu sama lain. Dengan demikian, karena persaingan ini, aplikasi yang berjalan pada server Linux NFS masih akan melihat file dikunci oleh klien NFS sebagai dikunci dengan kunci fcntl () / POSIX, apakah aplikasi pada klien menggunakan gaya BSD atau POSIX- kunci gaya. Jika aplikasi server menggunakan kawanan () kunci BSD, itu tidak akan melihat kunci yang digunakan klien NFS.

Ini sudah ketinggalan zaman sekarang. NFS4 mendukung penguncian di dalam protokol (tidak diperlukan daemon lockd atau mekanisme panggilan balik RPC) dan flock()metode Perl berfungsi dengan baik - kami menggunakannya dalam produksi.

Versi kernel yang sangat lama diimplementasikan flock(syscall) sebagai no-op pada NFS, dan hal-hal lain seperti penguncian rentang byte tidak didukung dengan benar. Di sinilah histeria berasal.