jika saya mematikan komputer segera setelah saya mengedit dan menyimpan file, kemungkinan besar perubahan saya akan hilang?
Mereka mungkin. Saya tidak akan mengatakan "kemungkinan besar", tetapi kemungkinannya bergantung pada banyak hal.
Cara mudah untuk meningkatkan kinerja penulisan file, adalah agar OS hanya meng-cache data, memberi tahu (berbohong kepada) aplikasi yang telah dilalui penulisan, dan kemudian benar-benar melakukan penulisan nanti. Ini sangat berguna jika ada aktivitas disk lain yang terjadi pada saat yang sama:OS dapat memprioritaskan membaca dan menulis nanti. Itu juga dapat menghapus kebutuhan untuk penulisan yang sebenarnya sepenuhnya, misalnya, dalam kasus di mana file sementara dihapus dengan cepat setelahnya.
Masalah caching lebih terasa jika penyimpanannya lambat. Menyalin file dari SSD cepat ke stik USB yang lambat mungkin akan melibatkan banyak cache tulis, karena stik USB tidak dapat mengikuti. Tapi cp Anda perintah kembali lebih cepat, sehingga Anda dapat terus bekerja, bahkan mungkin mengedit file yang baru saja disalin.
Tentu saja caching seperti itu memiliki kelemahan yang Anda catat, beberapa data mungkin hilang sebelum benar-benar disimpan. Pengguna akan jengkel jika editor mereka memberi tahu mereka bahwa penulisan berhasil, tetapi file tersebut sebenarnya tidak ada di disk. Itulah sebabnya ada fsync() panggilan sistem, yang seharusnya kembali hanya setelah file benar-benar masuk ke disk. Editor Anda dapat menggunakannya untuk memastikan data baik-baik saja sebelum melaporkan kepada pengguna bahwa penulisan berhasil.
Saya berkata, "seharusnya", karena drive itu sendiri mungkin mengatakan kebohongan yang sama ke OS dan mengatakan bahwa penulisan selesai, sedangkan file tersebut benar-benar hanya ada di cache tulis yang mudah menguap di dalam drive. Bergantung pada drive, mungkin tidak ada jalan lain.
Selain fsync() , ada juga sync() dan syncfs() panggilan sistem yang meminta sistem untuk memastikan semua penulisan seluruh sistem atau semua penulisan pada sistem file tertentu telah mengenai disk. Utilitas sync dapat digunakan untuk memanggil mereka.
Lalu ada juga O_DIRECT tandai ke open() , yang seharusnya "mencoba meminimalkan efek cache dari I/O ke dan dari file ini." Menghapus caching mengurangi kinerja, sehingga sebagian besar digunakan oleh aplikasi (database) yang melakukan caching sendiri dan ingin mengontrolnya.(O_DIRECT bukannya tanpa masalah, komentar tentangnya di halaman manual agak lucu.)
Apa yang terjadi pada power-out juga tergantung pada sistem file. Bukan hanya data file yang harus Anda perhatikan, tetapi juga metadata sistem file. Memiliki data file pada disk tidak banyak berguna jika Anda tidak dapat menemukannya. Memperluas file ke ukuran yang lebih besar saja akan memerlukan pengalokasian blok data baru, dan perlu ditandai di suatu tempat.
Bagaimana sistem file berurusan dengan perubahan metadata dan urutan antara metadata dan penulisan data sangat bervariasi. Misalnya, dengan ext4 , jika Anda menyetel flag mount data=journal , maka semua penulisan – bahkan penulisan data – melalui jurnal dan seharusnya lebih aman. Itu juga berarti mereka ditulis dua kali, jadi kinerjanya turun. Opsi default mencoba mengurutkan penulisan sehingga data ada di disk sebelum metadata diperbarui. Opsi lain atau sistem file lain mungkin lebih baik atau lebih buruk; Saya bahkan tidak akan mencoba studi komprehensif.
Dalam praktiknya, pada sistem yang dimuat ringan, file akan masuk ke disk dalam beberapa detik. Jika Anda berurusan dengan penyimpanan yang dapat dilepas, lepaskan sistem file sebelum menarik media untuk memastikan data benar-benar dikirim ke drive, dan tidak ada aktivitas lebih lanjut. (Atau minta lingkungan GUI Anda melakukannya untuk Anda.)
Ada sangat cara sederhana untuk membuktikan bahwa itu tidak bisa benar bahwa pengeditan file selalu langsung disimpan ke disk, yaitu fakta bahwa ada sistem file yang tidak didukung oleh disk sejak awal . Jika sistem file tidak memiliki disk di tempat pertama, maka itu tidak mungkin tulis perubahan ke disk, selamanya .
Beberapa contohnya adalah:
tmpfs, sistem file yang hanya ada di RAM (atau lebih tepatnya, di cache buffer)ramfs, sistem file yang hanya ada di RAM- apa saja sistem file jaringan (NFS, CIFS/SMB, AFS, AFP, …)
- apa saja sistem file virtual (
sysfs,procfs,devfs,shmfs, …)
Tetapi bahkan untuk sistem file yang didukung disk, ini biasanya tidak benar. Halaman Cara Merusak Database SQLite memiliki bab yang disebut Gagal menyinkronkan yang menjelaskan banyak cara berbeda di mana penulisan (dalam hal ini melakukan ke database SQLite) bisa gagal tiba di disk. SQLite juga memiliki kertas putih yang menjelaskan banyak rintangan yang harus Anda lewati untuk menjamin Komitmen Atom Dalam SQLite . (Perhatikan bahwa Atomic Write adalah masalah yang jauh lebih sulit daripada hanya Tulis , tetapi tentu saja menulis ke disk adalah sub-masalah penulisan atom, dan Anda juga dapat belajar banyak tentang masalah itu dari makalah ini.) Makalah ini memiliki bagian tentang Hal-Hal yang Bisa Salah yang menyertakan subbagian tentang Pembersihan Disk Tidak Lengkap yang memberikan beberapa contoh seluk-beluk halus yang mungkin mencegah penulisan mencapai disk (seperti pengontrol HDD melaporkan bahwa ia telah menulis ke disk padahal sebenarnya tidak - ya, ada produsen HDD yang melakukan ini, dan mungkin bahkan legal menurut spesifikasi ATA, karena kata-katanya ambigu dalam hal ini).
Memang benar bahwa sebagian besar sistem operasi, termasuk Unix, Linux, dan Windows menggunakan cache tulis untuk mempercepat operasi. Itu berarti mematikan komputer tanpa mematikannya adalah ide yang buruk dan dapat menyebabkan hilangnya data. Hal yang sama berlaku jika Anda melepas penyimpanan USB sebelum siap untuk dilepas.
Sebagian besar sistem juga menawarkan opsi untuk membuat penulisan menjadi sinkron. Artinya, data akan berada di disk sebelum aplikasi menerima konfirmasi sukses, dengan biaya yang lebih lambat.
Singkatnya, ada alasan mengapa Anda harus mematikan komputer dengan benar dan menyiapkan penyimpanan USB dengan benar untuk dihapus.