Apakah notifikasi kebakaran notifikasi saat penulisan dimulai atau ketika selesai?

Bayangkan dua proses, pembaca dan penulis, berkomunikasi melalui file biasa pada ext3 fs. Pembaca memiliki IN_MODIFYarloji tidak sah pada file. Penulis menulis 1000 byte ke file, dalam satu write()panggilan. Pembaca mendapat acara inotify, dan memanggil fstatfile tersebut. Apa yang dilihat Pembaca?

1. Apakah ada jaminan bahwa Reader akan mendapatkan kembali setidaknya 1000 untuk st_sizedi file? Dari eksperimen saya, sepertinya tidak.

2. Apakah ada jaminan bahwa Reader dapat benar-benar read()1000 byte?

Ini terjadi pada kotak I / O terikat serius. Misalnya, sarmenunjukkan waktu tunggu sekitar 1 detik. Dalam kasus saya Pembaca sebenarnya menunggu 10 detik SETELAH mendapatkan acara inotify sebelum menelepon stat, dan mendapatkan hasil yang terlalu kecil.

Apa yang saya harapkan adalah acara inotify tidak akan terkirim sampai file siap. Apa yang saya curigai sebenarnya terjadi adalah bahwa peristiwa inotify akan menyala SELAMA write()panggilan dalam Writer, dan data tersebut sebenarnya tersedia untuk proses lain pada sistem kapan pun ia siap. Dalam hal ini, 10s tidak cukup waktu.

Saya kira saya hanya mencari konfirmasi bahwa kernel benar-benar mengimplementasikan cara saya menebak. Juga, jika ada opsi, mungkin, untuk mengubah perilaku ini?

Akhirnya- apa gunanya memberi tahu, mengingat perilaku ini? Lagipula Anda hanya akan memilih file / direktori, setelah Anda mendapatkan acara, sampai data benar-benar tersedia. Sebaiknya lakukan itu selama ini, dan lupakan tentang tidak mengizinkan.

*** EDIT ** * * Oke, seperti yang sering terjadi, perilaku yang saya lihat sebenarnya masuk akal, sekarang saya mengerti apa yang sebenarnya saya lakukan. ^ _ ^

Saya sebenarnya merespons acara IN_CREATE di direktori tempat file tersebut berada. Jadi saya sebenarnya stat () 'ing file dalam menanggapi pembuatan file, belum tentu acara IN_MODIFY, yang mungkin akan tiba nanti.

Saya akan mengubah kode saya sehingga, setelah saya mendapatkan acara IN_CREATE, saya akan berlangganan IN_MODIFY pada file itu sendiri, dan saya tidak akan benar-benar mencoba membaca file sampai saya mendapatkan acara IN_MODIFY. Saya menyadari bahwa ada jendela kecil di sana di mana saya mungkin ketinggalan menulis ke file, tetapi ini dapat diterima untuk aplikasi saya, karena dalam kasus terburuk, file akan ditutup setelah jumlah detik maksimum.

Dari apa yang saya lihat di sumber kernel , inotify hanya aktif setelah penulisan selesai (mis. Tebakan Anda salah). Setelah pemberitahuan dipicu, hanya dua hal lagi terjadi di sys_write, fungsi yang mengimplementasikan writesyscall: pengaturan beberapa parameter penjadwal, dan memperbarui posisi pada file descriptor. Kode ini telah mirip sejauh 2.6.14 . Pada saat notifikasi menyala, file sudah memiliki ukuran baru.

Periksa hal-hal yang mungkin salah:

• Mungkin pembaca mendapatkan notifikasi lama, dari tulisan sebelumnya.
• Jika pembaca memanggil statdan kemudian memanggil readatau sebaliknya, sesuatu mungkin terjadi di antaranya. Jika Anda terus menambahkan file, menelepon statjaminan pertama bahwa Anda akan dapat membaca sejauh itu, tetapi ada kemungkinan bahwa lebih banyak data telah ditulis pada saat pembaca menelepon read, bahkan jika belum menerima notifikasi inotify.
• Hanya karena penulis menelepon writetidak berarti bahwa kernel akan menulis jumlah karakter yang diminta. Ada sangat sedikit keadaan di mana penulisan atom dijamin hingga ukuran berapa pun. Namun, setiap writepanggilan dijamin atomik: pada titik tertentu data belum ditulis, dan tiba-tiba n byte ditulis, di mana n adalah nilai balik writepanggilan tersebut. Jika Anda mengamati file yang ditulis sebagian, itu berarti bahwa writekembali kurang dari ukuran argumennya.

Alat yang berguna untuk menyelidiki apa yang terjadi termasuk:

• strace -tt
• subsistem auditd