Kesalahan disk senyap dan keandalan swap Linux

Pemahaman saya adalah bahwa hard drive dan SSD menerapkan beberapa koreksi kesalahan dasar di dalam drive, dan sebagian besar konfigurasi RAID misalnya mdadm akan bergantung pada ini untuk memutuskan kapan drive gagal untuk memperbaiki kesalahan dan perlu diambil offline. Namun, ini tergantung pada penyimpanan yang 100% akurat dalam diagnosis kesalahannya. Tidak demikian, dan konfigurasi umum seperti cermin RAID-1 dua-drive akan rentan: misalkan beberapa bit pada satu drive rusak secara diam-diam dan drive tidak melaporkan kesalahan baca. Dengan demikian, sistem file seperti btrfs dan ZFS menerapkan checksum mereka sendiri, agar tidak mempercayai firmware kereta buggy, kabel SATA glitchy, dan sebagainya.

Demikian pula, RAM juga dapat memiliki masalah keandalan dan karenanya kami memiliki RAM ECC untuk menyelesaikan masalah ini.

Pertanyaan saya adalah ini : apa cara kanonik untuk melindungi file swap Linux dari korupsi diam / busuk bit yang tidak tertangkap oleh drive firmware pada konfigurasi dua disk (yaitu menggunakan driver kernel garis utama)? Sepertinya saya bahwa konfigurasi yang tidak memiliki perlindungan end-to-end di sini (seperti yang disediakan oleh btrfs) agak meniadakan ketenangan pikiran yang dibawa oleh ECC RAM. Namun saya tidak bisa memikirkan cara yang baik:

• btrfs tidak mendukung swapfile sama sekali. Anda dapat mengatur perangkat loop dari file btrfs dan melakukan swap pada itu. Tapi itu punya masalah:
  • Penulisan acak tidak berkinerja baik: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
  • Saran untuk menonaktifkan copy-on-write juga akan menonaktifkan checksumming - sehingga mengalahkan seluruh poin dari latihan ini. Asumsi mereka adalah bahwa file data memiliki perlindungan internalnya sendiri.
• ZFS di Linux memungkinkan menggunakan ZVOL sebagai swap, yang saya kira bisa berfungsi: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - namun, dari bacaan saya, ZFS biasanya membutuhkan memori, dan membuatnya bekerja dalam swap -hanya aplikasi terdengar seperti beberapa pekerjaan mencari tahu. Saya pikir ini bukan pilihan pertama saya. Mengapa Anda harus menggunakan beberapa modul kernel out-of-tree hanya untuk memiliki swap yang andal berada di luar jangkauan saya - tentunya ada cara untuk mencapai hal ini dengan sebagian besar distribusi / kernel Linux modern di zaman sekarang?
• Sebenarnya ada utas pada mailing list kernel Linux dengan tambalan untuk mengaktifkan checksum dalam manajer memori itu sendiri, untuk alasan yang persis saya bahas dalam pertanyaan ini: http://thread.gmane.org/gmane.linux.kernel/989246 - sayangnya, sejauh yang saya tahu, tambalan itu mati dan tidak pernah berhasil di hulu karena alasan yang tidak saya ketahui. Sayang sekali, itu terdengar seperti fitur yang bagus. Di sisi lain, jika Anda memasang swap pada RAID-1 - jika korupsi di luar kemampuan checksum untuk memperbaiki, Anda ingin manajer memori mencoba membaca dari drive lain sebelum panik atau apa pun, yang merupakan mungkin di luar ruang lingkup apa yang harus dilakukan manajer memori.

Kesimpulan:

• RAM memiliki ECC untuk memperbaiki kesalahan
• File pada penyimpanan permanen memiliki btrf untuk memperbaiki kesalahan
• Swap telah ??? <--- ini pertanyaan saya

Kami percaya integritas data yang diambil dari swap karena perangkat keras penyimpanan memiliki checksum, CRC, dan semacamnya.

Dalam salah satu komentar di atas, Anda mengatakan:

benar, tetapi itu tidak akan melindungi terhadap bit membalik di luar disk itu sendiri

"Itu" artinya checksum disk di sini.

Itu benar, tetapi SATA menggunakan CRC 32-bit untuk perintah dan data. Dengan demikian, Anda memiliki 1 dalam 4 miliar peluang data yang rusak tidak terdeteksi antara disk dan pengontrol SATA. Itu berarti bahwa sumber kesalahan kontinu dapat memperkenalkan kesalahan sesering setiap 125 MiB ditransfer, tetapi sumber kesalahan acak yang jarang seperti sinar kosmik akan menyebabkan kesalahan tidak terdeteksi pada tingkat yang semakin kecil.

Sadarilah juga bahwa jika Anda memiliki sumber yang menyebabkan kesalahan tidak terdeteksi pada tingkat mendekati satu per 125 MiB yang ditransfer, kinerjanya akan mengerikan karena banyaknya kesalahan yang terdeteksi yang memerlukan transfer ulang. Pemantauan dan penebangan mungkin akan mengingatkan Anda tentang masalah pada waktunya untuk menghindari korupsi yang tidak terdeteksi.

Sedangkan untuk checksum media penyimpanan, setiap SATA (dan sebelum itu, PATA) disk menggunakan checksum per-sektor dari beberapa jenis. Salah satu fitur karakteristik hard disk "perusahaan" adalah sektor yang lebih besar yang dilindungi oleh fitur integritas data tambahan , sangat mengurangi kemungkinan kesalahan yang tidak terdeteksi.

Tanpa langkah-langkah seperti itu, tidak akan ada titik ke kumpulan sektor cadangan di setiap hard drive: drive itu sendiri tidak dapat mendeteksi sektor yang buruk, sehingga tidak akan pernah bisa menukar sektor baru di.

Di komentar lain, Anda bertanya:

jika SATA sangat dapat dipercaya, mengapa ada sistem file checksummed 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 hampir selama itu, karena sebagian besar data yang melewati sistem memori virtual sistem Anda adalah bagian dari proses yang berumur pendek.

Selain itu, uptime pada umumnya semakin pendek, seiring dengan meningkatnya frekuensi kernel dan libcpembaruan, virtualisasi, arsitektur cloud, dll.

Selain itu, sebagian besar data dalam swap secara inheren tidak digunakan dalam sistem yang dikelola dengan baik, menjadi salah satu yang tidak kehabisan RAM utama. Dalam sistem seperti itu, satu-satunya hal yang berakhir dengan swap adalah halaman yang tidak sering digunakan oleh program, jika pernah. Ini lebih umum daripada yang Anda duga. Kebanyakan pustaka dinamis yang ditautkan oleh program Anda memiliki rutinitas di dalamnya yang tidak digunakan oleh program Anda, tetapi pustaka tersebut harus dimuat ke dalam RAM oleh penghubung dinamis . Ketika OS melihat bahwa Anda tidak menggunakan semua teks program di perpustakaan, swap keluar, membuat ruang untuk kode dan data yang program Anda yang menggunakan. Jika halaman memori yang ditukar seperti itu rusak, siapa yang akan tahu?

Bandingkan ini dengan orang-orang seperti ZFS di mana kami berharap data akan disimpan secara permanen dan terus-menerus, sehingga tidak hanya bertahan di luar waktu aktif sistem saat ini, tetapi juga di luar kehidupan masing-masing perangkat penyimpanan yang terdiri dari sistem penyimpanan. ZFS dan sejenisnya memecahkan masalah dengan skala waktu kira-kira dua urutan besarnya lebih lama dari masalah diselesaikan dengan swap. Karena itu, kami memiliki persyaratan deteksi korupsi yang jauh lebih tinggi untuk ZFS daripada untuk Linux swap.

ZFS dan yang berbeda dari swap dengan cara kunci lain di sini: kami tidak menukar sistem file RAID bersama. Ketika beberapa perangkat swap digunakan pada satu mesin, itu skema JBOD , tidak seperti RAID-0 atau lebih tinggi. (misalnya skema swap file macOS , Linux swapon, dll.) Karena perangkat swap independen, bukan saling bergantung seperti dengan RAID, kita tidak perlu pemeriksaan ekstensif karena mengganti perangkat swap tidak melibatkan melihat perangkat swap saling bergantung lainnya untuk data yang harus masuk pada perangkat pengganti. Dalam istilah ZFS, kami tidak memasang ulang perangkat swap dari salinan berlebihan pada perangkat penyimpanan lain.

Semua ini berarti Anda harus menggunakan perangkat swap yang andal. Saya pernah menggunakan enclosure HDD USB eksternal seharga $ 20 untuk menyelamatkan kumpulan ZFS yang sakit, hanya untuk mengetahui bahwa enclosure itu sendiri tidak dapat diandalkan, memperkenalkan kesalahannya sendiri ke dalam proses. Cekungan ZFS yang kuat menyelamatkan saya di sini. Anda tidak bisa lolos dari perlakuan media penyimpanan yang angkuh dengan file swap. Jika perangkat swap sedang sekarat, dan dengan demikian mendekati kasus terburuk di mana itu bisa menyuntikkan kesalahan tidak terdeteksi setiap 125 MiB ditransfer, Anda hanya perlu menggantinya, ASAP.

Rasa paranoia secara keseluruhan dalam pertanyaan ini beralih ke contoh masalah jenderal Bizantium . Bacalah itu, renungkan tanggal 1982 di makalah akademis yang menjelaskan masalah itu ke dunia sains komputer, dan kemudian putuskan apakah Anda, pada 2019, memiliki pemikiran baru untuk menambah masalah ini. Dan jika tidak, maka mungkin Anda hanya akan menggunakan teknologi yang dirancang oleh tiga dekade lulusan CS yang semuanya tahu tentang Masalah Jenderal Bizantium.

Ini adalah tanah yang sangat 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 dari tim pengembangan kernel, Anda tidak akan berada dalam posisi untuk menambahkan secara material ke keadaan seni di sini. Masalah-masalah ini sudah ada di tangan, seperti yang telah Anda catat: ZFS, btrfs, ReFS ... Sebagai pengguna OS, Anda hanya harus 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, Anda setidaknya bisa meletakkannya di atas xfs atau ext4. Itu akan lebih baik daripada menggunakan partisi swap khusus.

dm-integritas

Lihat: Dokumentasi / device-mapper / dm-integrity.txt

dm-integritybiasanya akan digunakan dalam mode penjurnalan. Dalam kasus swap, 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-integritas pada setiap boot, untuk menghindari penangkapan kesalahan setelah shutdown yang tidak bersih.

Dalam pengumuman awaldm-integrity , penulis menyatakan preferensi untuk "perlindungan integritas data pada tingkat yang lebih tinggi" sebagai gantinya. Dalam hal swap, itu akan membuka kemungkinan menyimpan checksum dalam RAM. Namun, opsi itu membutuhkan modifikasi non-sepele untuk 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 ujung ke ujung?

Anda dapat berkonsultasi dengan vendor Anda. Saya tidak tahu bagaimana Anda bisa tahu jika 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 dalam tingkat kesalahan ).

Justru karena checksum di bidang pelindung terstandarisasi, secara teknis dimungkinkan untuk mengimplementasikan perintah DIX tanpa memberikan perlindungan apa pun untuk data saat istirahat. HBA (atau perangkat penyimpanan) baru saja membuat ulang checksum pada waktu baca. Pandangan ini dibuat cukup jelas oleh proyek DIX asli.

• DIF / DIX adalah checksum blok orthogonal ke logis
  • Kami masih mencintaimu, btrfs!
  • Kesalahan checksum blok logis digunakan untuk mendeteksi data yang rusak
  • Deteksi terjadi pada waktu BACA
  • ... yang mungkin berbulan-bulan kemudian, buffer asli hilang
  • Setiap salinan yang berlebihan mungkin juga buruk jika buffer asli rusak
• DIF / DIX 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 posting awal mereka tentang DIX menyebutkan kemungkinan menggunakan DIX antara OS dan HBA bahkan ketika drive tidak mendukung DIF.

Kebohongan total relatif tidak mungkin dalam konteks "perusahaan" di mana DIX saat ini digunakan; orang akan memperhatikannya. 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 misalnya sg_formatperintah.

Yang lebih mungkin adalah implementasi yang tidak mengikuti prinsip end-to-end yang sebenarnya . Untuk memberikan satu contoh, vendor disebutkan yang mendukung opsi checksum yang lebih lemah untuk DIX untuk menghemat siklus CPU, yang kemudian digantikan oleh checksum yang lebih kuat di bawah tumpukan. Ini berguna, tetapi tidak sepenuhnya melindungi ujung ke ujung.

Atau, OS dapat menghasilkan checksum sendiri dan menyimpannya di ruang tag aplikasi. Namun tidak ada dukungan untuk ini di Linux saat ini (v4.20) . Komentar, yang ditulis pada tahun 2014, menunjukkan ini mungkin karena "sangat sedikit perangkat penyimpanan yang benar-benar mengizinkan penggunaan ruang tag aplikasi". (Saya tidak yakin apakah ini merujuk pada perangkat penyimpanan itu sendiri, HBA, atau keduanya).

Perangkat DIX macam apa yang tersedia yang berfungsi dengan Linux?

Pemisahan data dan buffer metadata integritas serta pilihan dalam checksum disebut sebagai Data Integrity Extensions [DIX]. Karena ekstensi ini berada di luar ruang lingkup badan protokol (T10, T13), Oracle dan mitranya berusaha untuk menstandarkannya dalam Asosiasi Industri Jaringan Penyimpanan.

- v4.20 / Dokumentasi / blok / data-integritas.txt

Wikipedia memberi tahu saya bahwa DIF distandarisasi dalam NVMe 1.2.1. Untuk SCSI HBA, tampaknya agak sulit untuk dijabarkan jika kita tidak memiliki standar untuk menunjuk. Pada 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 menyediakan dukungan penuh untuk konfigurasi HBA dan array penyimpanan tertentu. DIF / DIX tidak didukung pada konfigurasi lain, tidak didukung untuk digunakan pada perangkat boot, dan tidak didukung pada tamu yang divirtualisasi.

Saat ini, vendor berikut diketahui memberikan dukungan ini ...

- RHEL 7.5 Catatan Rilis, Bab 16. Penyimpanan

Semua perangkat keras yang disebutkan dalam catatan rilis RHEL 7.5 adalah Fibre Channel.

Saya tidak tahu pasar ini. Kedengarannya seperti DIX mungkin menjadi lebih banyak tersedia di server di masa depan. Saya tidak tahu alasan mengapa itu akan tersedia untuk disk SATA konsumen - sejauh yang saya tahu bahkan tidak ada standar de-facto untuk format perintah. Saya akan tertarik untuk melihat apakah itu tersedia lebih luas di NVMe.

Swap telah ??? <--- ini pertanyaan saya

Swap masih tidak dilindungi di Linux (tetapi lihat UPD).

Yah, tentu saja ada ZFS di Linux yang mampu menjadi penyimpanan swap tetapi masih ada penguncian dalam beberapa keadaan - sehingga secara efektif mencabut opsi itu.

Btrfs masih tidak dapat menangani file swap . Mereka menyebutkan kemungkinan penggunaan loopback meskipun tercatat memiliki kinerja yang buruk. Ada indikasi yang tidak jelas bahwa Linux 5 akhirnya bisa (?) ...

Tambalan untuk melindungi swap konvensional itu sendiri dengan checksum tidak membuatnya menjadi arus utama.

Jadi, semuanya: tidak. Linux masih memiliki celah di sana.

UPD. : Sebagai @ sourcejedi poin ada alat seperti dm-integritas. Kernel Linux sejak versi 4.12 mendapatkan target device-mapper yang dapat digunakan untuk menyediakan checksum untuk semua perangkat blok umum dan yang untuk swap tidak terkecuali. Perkakas tidak secara luas dimasukkan ke dalam distro besar dan kebanyakan dari mereka tidak memiliki dukungan dalam sub-sistem udev, tetapi pada akhirnya ini akan berubah. Ketika dipasangkan dengan penyedia redundansi, katakan dimasukkan ke atas MD alias Linux Software RAID, seharusnya tidak hanya untuk mendeteksi busuk bit tetapi juga untuk merutekan ulang permintaan I / O ke data yang sehat karena dm-integritas akan menunjukkan ada masalah dan MD harus menanganinya.

Saya tidak berpikir bahwa ada cara "kanonik", jadi berikut ini adalah pendapat pribadi saya.

Setelah memantau kemajuan btrfs dari sudut pandang pengguna potensial, saya harus mengatakan bahwa itu masih belum jelas bagi saya. Ada fitur yang matang dan siap digunakan untuk produksi, dan ada fitur yang tampaknya belum matang dan berbahaya untuk digunakan.

Secara pribadi, saya tidak punya waktu untuk memutuskan fitur mana yang akan digunakan dan mana yang tidak, lepaskan waktu yang saya perlukan untuk mencari tahu cara mematikan atau pada fitur ini.

Sebaliknya, ZFS sangat solid dan matang (IMHO). Jadi, untuk menjawab pertanyaan Anda, saya akan menggunakan ZFS (omong-omong, tidak menghabiskan banyak memori - lihat di bawah).

Tetapi bagi Anda, btrf mungkin merupakan pilihan yang tepat karena Anda sudah menggunakannya (jika saya benar), dan salah satu komentar di atas menunjukkan bagaimana menggunakannya untuk swap.

Secara kebetulan, saya telah menempatkan beberapa server Linux pada ZFS selama beberapa hari terakhir, setiap kali termasuk sistem file root dan swap. Sebelum saya melakukan ini, saya telah melakukan penelitian yang sangat menyeluruh, yang membutuhkan waktu beberapa hari. Ringkasan singkat tentang apa yang telah saya pelajari:

Konsumsi memori ZFS

Ada kesalahpahaman umum tentang konsumsi memori ZFS. ZFS umumnya tidak mengkonsumsi banyak memori; sebenarnya, ini berjalan dengan TB penyimpanan pada mesin dengan 2 GB RAM. Hanya jika Anda menggunakan deduplikasi (dinonaktifkan secara default), maka diperlukan banyak dan banyak RAM.

Deteksi / koreksi kesalahan perangkat keras

Apakah SATA, PATA, RAID atau mekanisme deteksi / koreksi kesalahan lainnya cukup untuk integritas data adalah subjek yang menyebabkan diskusi tanpa akhir dan bahkan nyala perang di semua tempat di internet. Secara teori, perangkat penyimpanan perangkat keras harus melaporkan (dan mungkin memperbaiki) setiap kesalahan yang ditemui, dan perangkat keras transmisi data di semua tingkatan (chipset, memori, dll.) Juga dapat melakukannya.

Yah, mereka tidak dalam semua kasus, atau mereka bereaksi surpringly terhadap kesalahan. Sebagai contoh, mari kita ambil konfigurasi RAID5 yang khas. Biasanya, jika satu disk memiliki masalah, itu akan melaporkannya ke RAID yang pada gilirannya membangun data untuk dibaca dari disk lain dan meneruskannya, tetapi juga menulis kembali ke disk yang rusak (yang pada gilirannya mungkin memetakan kembali sektor sebelum menulis data); jika disk yang sama melaporkan terlalu banyak kesalahan, RAID akan membuatnya offline dan memberi tahu administrator (jika dikonfigurasi dengan benar).

Sejauh ini, sangat bagus, tetapi ada kasus di mana data yang salah keluar dari disk tanpa disk melaporkan kesalahan (lihat bagian selanjutnya). Kebanyakan RAID dapat mendeteksi situasi ini menggunakan informasi paritas, tetapi reaksinya bodoh: Alih-alih melaporkan kesalahan dan menghentikan data yang diteruskan, mereka hanya akan menghitung ulang paritas berdasarkan data yang salah dan menulis paritas baru untuk masing-masing disk, dengan demikian menandai data yang salah sebagai benar selamanya.

Apakah itu perilaku yang masuk akal? Sejauh yang saya tahu, sebagian besar pengontrol RAID5 perangkat keras dan bahkan md RAID Linux beroperasi dengan cara ini.

Saya tidak tahu tentang koreksi kesalahan btrfs, tetapi Anda akhirnya harus membaca dokumen dengan cermat sekali lagi, terutama jika Anda menggunakan RAID btrfs.

Membusuk sedikit diam

Terlepas dari semua perang api dan (pseudo-) diskusi ilmiah: Realitas sebagian besar berbeda dari teori, dan busuk bit bisu pasti terjadi walaupun teori mungkin menyatakan sebaliknya (bisikan bot bisu biasanya berarti bahwa data pada penyimpanan perangkat keras rusak tanpa perangkat penyimpanan melaporkan suatu kesalahan ketika data ini dibaca, tapi saya akan menambahkan bit membalik di mana saja di jalur transmisi ke definisi ini).

Bahwa ini terjadi bukan pendapat pribadi saya: Setidaknya Google, Amazon dan CERN telah menerbitkan buku putih terperinci yang membahas hal itu. Makalah tersedia untuk umum untuk diunduh secara gratis. Mereka telah melakukan eksperimen sistematis dengan beberapa juta hard disk dan ratusan ribu server / perangkat penyimpanan, baik karena mereka memiliki masalah dengan korupsi data yang tidak terdeteksi atau karena mereka ingin tahu apa yang harus dilakukan untuk mencegahnya sebelum hal itu terjadi.

Singkatnya, data di server pertanian mereka telah rusak dengan tingkat yang secara signifikan lebih tinggi daripada statistik MTBF atau teori lain akan membiarkannya. Secara signifikan lebih tinggi, maksud saya urutan besarnya.

Jadi bit busuk diam, yaitu korupsi data yang tidak terdeteksi di setiap titik di jalur transmisi, adalah masalah kehidupan nyata.

Data seumur hidup

Warren Young benar ketika dia mengatakan bahwa data swap memiliki masa hidup yang singkat. Tapi saya ingin menambahkan pertimbangan berikut: Tidak hanya data (dalam arti dokumen) masuk ke swap, tetapi (mungkin bahkan lebih mungkin) bagian dari O / S atau perangkat lunak lain yang berjalan . Jika saya memiliki MP3 dalam swap, saya bisa hidup dengan sedikit flipping. Jika (karena situasi yang ekstrem) bagian-bagian dari perangkat lunak server httpd produksi saya sedang dalam swap, saya sama sekali tidak dapat hidup dengan bit flipping yang kemudian mengarah pada mengeksekusi kode yang rusak jika tidak terdeteksi.

Epilog

Bagi saya, ZFS memecahkan masalah ini, atau, lebih tepatnya, memindahkan mereka dari disk ke memori dan dengan demikian mengurangi kemungkinan busuk bit diam oleh beberapa urutan besarnya. Selain itu, jika dikonfigurasi dengan benar (mis. Mirror bukan RAID), ini memberikan koreksi kesalahan yang bersih dan masuk akal yang berfungsi seperti yang diharapkan dan dapat dipahami dengan mudah.

Setelah mengatakan ini, harap dicatat bahwa Anda tidak akan pernah mendapatkan keamanan absolut. Secara pribadi, saya mempercayai RAM ECC saya lebih dari disk saya, dan saya yakin bahwa ZFS dengan checksum ujung-ke-ujungnya mengurangi kemungkinan masalah dengan urutan besarnya. Saya tidak akan merekomendasikan menggunakan ZFS tanpa RAM ECC.

Penafian: Saya sama sekali tidak terkait dengan vendor atau pengembang ZFS. Ini berlaku untuk semua varian (garpu) ZFS. Saya hanya menjadi penggemar itu dalam beberapa hari terakhir ...