Sebuah process dapat tetap memiliki rentang address mmap() yang valid setelah operasi lain mengecilkan backing file, lalu menerima SIGBUS ketika menyentuh mapped page yang berada di luar akhir file baru. Mapping-nya sendiri tidak hilang. Backing object-nya tidak lagi mencakup setiap page yang semula direferensikan oleh virtual mapping.
Boundary ini mudah terlewat karena mapping lifetime dan file size adalah state yang terpisah. Menutup file descriptor awal tidak membatalkan mapping yang sudah terbentuk, dan mengecilkan file tidak bertindak seperti munmap() pada setiap process yang memetakannya.
Virtual mapping dapat hidup lebih lama daripada backing storage
Untuk regular file mapping, mmap() membentuk virtual address yang terkait dengan offset di file. Mapping length yang diminta mendeskripsikan rentang address space; ia tidak membekukan file pada ukuran saat itu.
Misalkan sebuah process memetakan 16 KiB dari file berukuran 16 KiB. Process kedua lalu melakukan truncate pada file tersebut menjadi 4 KiB. Process pertama masih dapat memiliki virtual mapping 16 KiB yang tercatat di address space-nya. Namun, tidak semua access menghasilkan outcome yang sama.
Address yang berkaitan dengan bagian file yang masih ada dapat tetap digunakan. Whole mapped page di luar akhir yang baru tidak lagi memiliki file storage di belakangnya. Di Linux, menyentuh page tersebut dapat menghasilkan SIGBUS.
Ini berbeda dari mengakses address yang tidak dipetakan. munmap() menghapus mapping, dan reference berikutnya ke address tersebut merupakan invalid virtual-memory access yang umumnya dilaporkan sebagai SIGSEGV. Truncation meninggalkan kondisi berbeda: mapping masih ada, tetapi mapped object tidak dapat memenuhi file offset yang direferensikan.
File size diperiksa saat akses terjadi
Memory-mapped I/O membuat load dan store biasa bergantung pada backing-object state yang dapat berubah secara independen. Sebuah page mungkin sudah resident, atau akses berikutnya mungkin memerlukan kernel menyelesaikan page fault. File truncation mengubah offset mana yang masih valid dalam object.
POSIX menetapkan bahwa ketika ftruncate() mengurangi ukuran mapped file, whole page di luar akhir file baru dibuang. Reference ke page yang dibuang tersebut menghasilkan SIGBUS. Linux mendokumentasikan signal yang sama untuk akses ke mapped page di luar akhir mapped file.
Hasilnya adalah concurrency boundary antara pengguna virtual memory dan mutasi file size. Pointer yang masih berada di dalam panjang mmap() semula bukan bukti yang cukup bahwa backing file offset-nya masih ada.
Final partial page adalah kasus berbeda
Akhir file biasanya tidak sejajar dengan system page size. Hal ini menciptakan boundary terpisah dari whole page di luar end-of-file.
Untuk file yang byte terakhirnya berada di tengah sebuah page, Linux mengisi sisa byte pada page tersebut dengan nol ketika dipetakan. Modifikasi pada byte di luar file end dalam final partial page tidak ditulis kembali ke file. Whole page setelah object end adalah region yang terkait dengan SIGBUS saat diakses.
Perbedaan ini penting ketika target truncation tidak page-aligned. Mapping dapat memiliki final page yang sebagian berkaitan dengan file dan sebagian berada di luar logical size. Kode yang menganggap setiap byte hingga page boundary sebagai durable file content dapat diam-diam bergantung pada byte yang tidak memiliki representasi di file.
Atomic replacement menghindari mutasi inode aktif
Bentuk kegagalan yang umum di production terjadi ketika satu process memetakan data file sementara process lain memperbaruinya in-place. Menulis ulang melalui inode yang sama dapat mengekspos transisi ukuran kepada mapped reader. Urutan truncate-then-write sangat berisiko karena reader dapat melihat object yang sudah dipendekkan sebelum replacement data selesai ditulis.
Mengganti pathname dengan file baru yang sudah ditulis memiliki mapping semantics berbeda. Existing mapping terus merujuk ke file object lama, sedangkan open berikutnya melalui pathname dapat mencapai replacement. Pathname update tidak mengarahkan ulang established mapping ke inode baru.
Properti ini membuat file replacement berbeda secara material dari in-place truncation untuk mapped reader. Ia tidak dengan sendirinya memberi seluruh durability atau coordination guarantee, tetapi menghindari pengecilan object di bawah mapping yang sudah merujuk kepadanya.
Signal handling bukan recovery boundary umum
Menangkap SIGBUS tidak mengubah arbitrary mapped access menjadi mekanisme retry yang aman. Fault dapat muncul dari application load biasa yang dihasilkan compiled code, dan melanjutkan execution memerlukan strategi valid untuk faulting instruction dan mapping state. Concurrent file mutation juga dapat terus berlangsung setelah handler berjalan.
Sistem yang mengizinkan mapped reader bersamaan dengan file replacement biasanya menempatkan consistency boundary di luar memory access individual. Immutable file generation, descriptor-based handoff, versioned path, atau explicit coordination menjaga ukuran mapped object tetap stabil selama reader mungkin melakukan dereference.
Constraint utamanya adalah stabilitas object, bukan validitas pointer. Mapped address dapat tetap ada di process saat file range di balik address tersebut sudah tidak ada.