Kami memercayai integritas data yang diambil dari swap karena perangkat keras penyimpanan memiliki checksum, CRC, dan semacamnya.
Di salah satu komentar di atas, Anda mengatakan:
benar, tetapi itu tidak akan melindungi dari bit membalik di luar disk itu sendiri
"Itu" berarti checksum disk di sini.
Itu benar, tetapi SATA menggunakan CRC 32-bit untuk perintah dan data. Dengan demikian, Anda memiliki peluang 1 banding 4 miliar untuk merusak data secara tidak terdeteksi antara disk dan pengontrol SATA. Itu berarti bahwa sumber kesalahan berkelanjutan dapat menyebabkan kesalahan sesering setiap 125 MiB yang ditransfer, tetapi sumber kesalahan acak yang langka seperti sinar kosmik akan menyebabkan kesalahan yang tidak terdeteksi dengan kecepatan yang sangat kecil.
Sadarilah juga bahwa jika Anda memiliki sumber yang menyebabkan kesalahan tidak terdeteksi dengan kecepatan mendekati satu per 125 MiB yang ditransfer, kinerja akan mengerikan karena tingginya jumlah terdeteksi kesalahan yang memerlukan transfer ulang. Pemantauan dan logging mungkin akan memberi tahu Anda tentang masalah ini tepat waktu untuk menghindari korupsi yang tidak terdeteksi.
Adapun checksum media penyimpanan, setiap disk SATA (dan sebelumnya, PATA) menggunakan checksum per sektor dari beberapa jenis. Salah satu fitur karakteristik hard disk "perusahaan" adalah sektor yang lebih besar dilindungi oleh fitur integritas data tambahan, sehingga sangat mengurangi kemungkinan kesalahan yang tidak terdeteksi.
Tanpa tindakan seperti itu, tidak akan ada gunanya kumpulan sektor cadangan di setiap hard drive:drive itu sendiri tidak dapat mendeteksi sektor yang buruk, sehingga tidak akan pernah dapat menukar sektor baru.
Di komentar lain, Anda bertanya:
jika SATA sangat dapat dipercaya, mengapa ada sistem file checksum seperti ZFS, btrfs, ReFS?
Secara umum, kami tidak meminta swap untuk menyimpan data jangka panjang. Batas penyimpanan swap adalah waktu aktif sistem, dan sebagian besar data dalam swap tidak bertahan selama itu, karena sebagian besar data yang melewati sistem memori virtual sistem Anda berasal dari proses yang berumur lebih pendek.
Selain itu, waktu aktif umumnya semakin pendek selama bertahun-tahun, dengan peningkatan frekuensi kernel dan libc pembaruan, virtualisasi, arsitektur cloud, dll.
Selain itu, sebagian besar data dalam swap secara inheren tidak digunakan dalam sistem yang dikelola dengan baik, menjadi sistem yang tidak kehabisan RAM utama. Dalam sistem seperti itu, satu-satunya hal yang berakhir dengan swap adalah halaman yang jarang digunakan oleh program, jika pernah. Ini lebih umum daripada yang Anda duga. Sebagian besar pustaka dinamis yang ditautkan oleh program Anda memiliki rutinitas di dalamnya yang tidak digunakan oleh program Anda, tetapi harus dimuat ke dalam RAM oleh penghubung dinamis. Saat OS melihat bahwa Anda tidak menggunakan semua teks program di pustaka, OS akan menukarnya, memberikan ruang untuk kode dan data yang ada program Anda menggunakan. Jika halaman memori yang ditukar seperti itu rusak, siapa yang akan tahu?
Bandingkan ini dengan ZFS di mana kami mengharapkan data disimpan secara tahan lama dan terus-menerus, sehingga tidak hanya bertahan melebihi waktu aktif sistem saat ini, tetapi juga melampaui masa pakai perangkat penyimpanan individual yang terdiri dari sistem penyimpanan. ZFS dan semacamnya memecahkan masalah dengan skala waktu kira-kira dua kali lipat lebih lama dari masalah yang diselesaikan dengan swap. Oleh karena itu, kami memiliki persyaratan deteksi korupsi yang jauh lebih tinggi untuk ZFS daripada Linux swap.
ZFS dan semacamnya berbeda dari swap dengan cara kunci lain di sini:kami tidak melakukan RAID menukar sistem file secara bersamaan. Saat beberapa perangkat swap digunakan pada satu mesin, ini adalah skema JBOD, tidak seperti RAID-0 atau lebih tinggi. (misalnya skema file swap berantai macOS, swapon Linux , dll.) Karena perangkat swap bersifat independen, bukan saling bergantung seperti pada RAID, kami tidak memerlukan checksum yang ekstensif karena mengganti perangkat swap tidak melibatkan melihat perangkat swap lain yang saling bergantung untuk data yang seharusnya masuk ke perangkat pengganti . Dalam ketentuan ZFS, kami tidak melakukan resilver menukar perangkat dari salinan redundan di perangkat penyimpanan lain.
Semua ini berarti Anda harus menggunakan perangkat swap yang andal. Saya pernah menggunakan enklosur HDD USB eksternal seharga $20 untuk menyelamatkan kumpulan ZFS yang sakit, hanya untuk menemukan bahwa enklosur itu sendiri tidak dapat diandalkan, menyebabkan kesalahannya sendiri ke dalam proses. Checksumming ZFS yang kuat menyelamatkan saya di sini. Anda tidak dapat lolos dengan perlakuan angkuh terhadap media penyimpanan dengan file swap. Jika perangkat swap sedang sekarat, dan dengan demikian mendekati kasus terburuk di mana ia dapat menyuntikkan kesalahan yang tidak terdeteksi setiap 125 MiB yang ditransfer, Anda hanya perlu menggantinya, secepatnya.
Rasa paranoia secara keseluruhan dalam pertanyaan ini beralih ke contoh masalah jenderal Bizantium. Bacalah itu, renungkan tanggal 1982 di makalah akademis yang menjelaskan masalah tersebut ke dunia ilmu komputer, lalu putuskan apakah Anda, di tahun 2019, memiliki pemikiran segar untuk ditambahkan ke masalah ini. Dan jika tidak, mungkin Anda hanya akan menggunakan teknologi yang dirancang oleh lulusan CS selama tiga dekade yang semuanya mengetahui tentang Masalah Jenderal Bizantium.
Ini tanah yang diinjak dengan baik. Anda mungkin tidak dapat menemukan ide, keberatan, atau solusi yang belum pernah dibahas sampai mati di jurnal ilmu komputer.
SATA tentu saja tidak sepenuhnya dapat diandalkan, tetapi kecuali jika Anda akan bergabung dengan akademisi atau salah satu tim pengembangan kernel, Anda tidak akan berada dalam posisi untuk menambah materi di sini. Masalah-masalah ini sudah ditangani dengan baik, seperti yang telah Anda catat:ZFS, btrfs, ReFS... Sebagai pengguna OS, Anda hanya perlu percaya bahwa pembuat OS menangani masalah ini untuk Anda, karena mereka juga tahu tentang Jenderal Bizantium.
Saat ini tidak praktis untuk meletakkan file swap Anda di atas ZFS atau Btrfs, tetapi jika hal di atas tidak meyakinkan Anda, setidaknya Anda bisa meletakkannya di atas xfs atau ext4. Itu akan lebih baik daripada menggunakan partisi swap khusus.
Tukar punya??? <--- ini pertanyaan saya
Swap masih tidak terlindungi di Linux (tetapi lihat UPD).
Yah, tentu saja ada ZFS di Linux yang mampu menjadi penyimpanan swap tetapi masih ada penguncian dalam keadaan tertentu — sehingga mencabut opsi itu secara efektif.
Btrf masih tidak bisa menangani file swap. Mereka menyebutkan kemungkinan penggunaan loopback meskipun kinerjanya buruk. Ada indikasi yang tidak jelas bahwa Linux 5 akhirnya bisa memilikinya(?)…
Tambalan untuk melindungi swap konvensional itu sendiri dengan checksum tidak membuatnya menjadi arus utama.
Jadi, semuanya:tidak. Linux masih memiliki celah di sana.
UPD. :Seperti yang ditunjukkan oleh @sourcejedi, ada alat seperti dm-integrity. Kernel Linux sejak versi 4.12 telah mendapatkan target pemetaan perangkat yang dapat digunakan untuk menyediakan checksum ke perangkat blok umum apa pun dan yang untuk swap tidak terkecuali. Perkakas tidak secara luas dimasukkan ke dalam distro utama dan kebanyakan dari mereka tidak memiliki dukungan apa pun dalam subsistem udev, tetapi pada akhirnya hal ini akan berubah. Ketika dipasangkan dengan penyedia redundansi, katakanlah diletakkan di atas MD alias Linux Software RAID, seharusnya tidak hanya dapat mendeteksi pembusukan bit tetapi juga untuk merutekan ulang permintaan I/O ke data yang sehat karena dm-integrity akan menunjukkan ada masalah dan MD harus menanganinya.
dm-integritas
Lihat:Dokumentasi/device-mapper/dm-integrity.txt
dm-integrity biasanya akan digunakan dalam mode penjurnalan. Dalam kasus pertukaran, Anda dapat mengatur untuk melakukannya tanpa penjurnalan. Ini secara signifikan dapat menurunkan overhead kinerja. Saya tidak yakin apakah Anda perlu memformat ulang partisi swap-over-integrity pada setiap boot, untuk menghindari terjadinya kesalahan setelah shutdown yang tidak bersih.
Pada pengumuman awal dm-integrity , penulis menyatakan preferensi untuk "perlindungan integritas data pada tingkat yang lebih tinggi". Dalam kasus swap, itu akan membuka kemungkinan menyimpan checksum di RAM. Namun, opsi itu akan memerlukan modifikasi non-sepele pada kode swap saat ini, dan meningkatkan penggunaan memori. (Kode saat ini melacak swap secara efisien menggunakan luasan, bukan halaman/sektor individual).
DIF/DIX?
Dukungan DIX ditambahkan oleh Oracle di Linux 2.6.27 (2008).
Apakah menggunakan DIX memberikan integritas end-to-end?
Anda dapat berkonsultasi dengan vendor Anda. Saya tidak tahu bagaimana Anda bisa tahu apakah mereka berbohong tentang hal itu.
DIX diperlukan untuk melindungi data dalam penerbangan antara OS (sistem operasi) dan HBA .
DIF dengan sendirinya meningkatkan perlindungan untuk data dalam penerbangan antara HBA dan perangkat penyimpanan . (Lihat juga:presentasi dengan beberapa angka tentang perbedaan tingkat kesalahan).
Justru karena checksum di bidang penjaga dibakukan, secara teknis dimungkinkan untuk mengimplementasikan perintah DIX tanpa memberikan apa pun perlindungan untuk data saat istirahat. Mintalah HBA (atau perangkat penyimpanan) membuat ulang checksum pada waktu baca. Prospek ini dibuat cukup jelas oleh proyek DIX asli.
- DIF/DIX adalah ortogonal ke checksum blok logis
- Kami masih mencintaimu, btrfs!
- Error checksum blok logis digunakan untuk mendeteksi data yang rusak
- Deteksi terjadi pada waktu BACA
- ... yang bisa berbulan-bulan kemudian, buffer asli hilang
- Salinan apa pun yang berlebihan juga dapat menjadi buruk jika buffer asli rusak
- DIF/DIX adalah tentang secara proaktif mencegah korupsi
- Mencegah data buruk disimpan di disk sejak awal
- ... dan mencari tahu tentang masalah sebelum buffer asli dihapus dari memori
-- lpc08-data-integrity.pdf dari oss.oracle.com
Salah satu postingan awal mereka tentang DIX menyebutkan kemungkinan penggunaan DIX antara OS dan HBA meskipun drive tidak mendukung DIF.
Kebohongan total relatif tidak mungkin dalam konteks "perusahaan" di mana DIX saat ini digunakan; orang akan menyadarinya. Juga, DIF didasarkan pada perangkat keras yang ada yang dapat diformat dengan sektor 520-byte. Protokol untuk menggunakan DIF diduga mengharuskan Anda memformat ulang drive terlebih dahulu, lihat mis. sg_format memerintah.
Yang lebih mungkin adalah implementasi yang tidak mengikuti prinsip end-to-end yang sebenarnya. Sebagai contoh, disebutkan vendor yang mendukung opsi checksum yang lebih lemah untuk DIX guna menghemat siklus CPU, yang kemudian digantikan oleh checksum yang lebih kuat di bagian bawah tumpukan. Ini berguna, tetapi ini bukan perlindungan menyeluruh yang lengkap.
Alternatifnya, OS dapat membuat checksum sendiri dan menyimpannya di ruang tag aplikasi. Namun tidak ada dukungan untuk ini di Linux saat ini (v4.20). Komentar tersebut, yang ditulis pada tahun 2014, menyarankan hal ini mungkin karena "sangat sedikit perangkat penyimpanan yang benar-benar mengizinkan penggunaan ruang tag aplikasi". (Saya tidak yakin apakah ini mengacu pada perangkat penyimpanan itu sendiri, HBA, atau keduanya).
Perangkat DIX seperti apa yang tersedia dan bekerja dengan Linux?
Pemisahan buffer metadata data dan integritas serta pilihan dalam checksum disebut sebagai Ekstensi Integritas Data [DIX]. Karena ekstensi ini berada di luar cakupan badan protokol (T10, T13), Oracle dan mitranya mencoba untuk membakukannya dalam Storage Networking Industry Association.
-- v4.20/Documentation/block/data-integrity.txt
Wikipedia memberi tahu saya bahwa DIF distandarisasi dalam NVMe 1.2.1. Untuk HBA SCSI, tampaknya agak sulit untuk menjelaskannya jika kami tidak memiliki standar untuk ditunjukkan. Saat ini mungkin paling tepat untuk berbicara tentang dukungan "Linux DIX" :-). Ada perangkat yang tersedia:
SCSI T10 DIF/DIX [sic] didukung penuh di Red Hat Enterprise Linux 7.4, asalkan vendor perangkat keras telah memenuhi syarat dan memberikan dukungan penuh untuk HBA tertentu dan konfigurasi storage array. DIF/DIX tidak didukung pada konfigurasi lain, tidak didukung untuk digunakan pada perangkat boot, dan tidak didukung pada tamu virtual.
Saat ini, vendor berikut diketahui menyediakan dukungan ini...
-- Catatan Rilis RHEL 7.5, Bab 16. Penyimpanan
Semua perangkat keras yang disebutkan dalam catatan rilis RHEL 7.5 adalah Fibre Channel.
Saya tidak tahu pasar ini. Sepertinya DIX akan tersedia lebih luas di server di masa mendatang. Saya tidak tahu alasan mengapa ini tersedia untuk disk SATA konsumen - sejauh yang saya tahu bahkan tidak ada standar de-facto untuk format perintah. Saya akan tertarik untuk melihat apakah ini tersedia lebih luas di NVMe.