deteksi dan koreksi bit busuk dengan mdadm

17

Saya akan mengatur ulang semua HDD saya di nas box linux rumah saya dan ingin menggunakan raid mdadm untuk perlindungan data dan fleksibilitasnya untuk membentuk kembali array. Namun, sebelum saya menggunakan mdadm untuk ini, saya ingin tahu bagaimana menangani bit busuk . Khususnya jenis bit busuk yang tidak menghasilkan pesan kesalahan baca yang tidak dapat dipulihkan yang dikirim dari HDD.

Mengingat bahwa saya akan kemungkinan besar akan menggunakan setidaknya 21TB dari HDD di 8 disk di nas dan berbagai kutipan pada probabilitas dari kegagalan pada HDD, aku berpikir bahwa selama membangun kembali dari kegagalan disk tunggal aku cukup mungkin untuk pertemuan beberapa bentuk bit busuk pada disk yang tersisa. Jika ini merupakan kesalahan baca yang tidak dapat dipulihkan pada 1 drive, drive tersebut benar-benar melaporkannya sebagai kesalahan, saya percaya itu seharusnya baik-baik saja dengan raid6 (bukan?). Namun jika data yang dibaca dari disk buruk tetapi tidak dilaporkan oleh disk, maka saya tidak bisa melihat bagaimana ini dapat secara otomatis diperbaiki bahkan dengan raid6. Apakah ini sesuatu yang perlu kita perhatikan? Mengingat artikel Ini adalah 2010 dan RAID5 masih berfungsi, dan pengalaman sukses saya sendiri di rumah dan di tempat kerja, semuanya tidak serta merta seperti kesedihan dan pemasaran yang ingin kita percayai, tetapi saya benci harus memulihkan dari cadangan hanya karena HDD gagal.

Mengingat bahwa pola penggunaannya adalah, tulis paling banyak beberapa kali, dan bacalah sesekali, saya perlu melakukan scrubbing data . Saya melihat di archlinux wiki perintah mdadm untuk data menggosok array

echo check > /sys/block/md0/md/sync_action

kemudian untuk memantau perkembangannya

cat /proc/mdstat

Menurut saya ini akan membaca semua sektor semua disk dan memeriksa apakah data cocok dengan paritas dan sebaliknya. Meskipun saya perhatikan ada penekanan besar dalam dokumen untuk mengatakan bahwa ada keadaan signifikan bahwa operasi "pemeriksaan" tidak akan dapat memperbaiki secara otomatis, hanya mendeteksi, dan akan menyerahkannya kepada pengguna untuk memperbaikinya.

Level mdadm RAID apa yang harus saya pilih untuk memaksimalkan perlindungan saya dari bit busuk dan langkah pemeliharaan serta perlindungan apa yang harus saya lakukan? Dan apa yang tidak akan melindungi saya dari ini?

Sunting: Saya tidak ingin memulai RAID vs ZFS atau QA teknologi lainnya. Saya ingin tahu secara khusus tentang serangan mdadm. Itu juga mengapa saya bertanya tentang Unix & Linux dan bukan pada SuperUser .

Sunting: adalah jawabannya: mdadm hanya dapat memperbaiki URE yang dilaporkan oleh sistem disk selama scrub data dan mendeteksi busuk bit diam selama scrub tetapi tidak dapat / tidak akan memperbaikinya?

raid mdadm BeowulfNode42
sumber
Sejauh perlindungan data berjalan, manfaat utama yang saya lihat di zfs adalah menggosok lokasi disk setiap kali Anda membaca file. Inilah sebabnya mengapa saya saat ini mengaturnya dengan zfs. Tapi saya tetap harus melakukan scrub penuh secara teratur. Saya memiliki 2 zfs pools masing-masing dengan 3 disk, dan saya ingin meng-upgrade ke sistem 8 disk di mana drive mana pun dapat gagal dan masih akan ada 1 drive yang lebih redundan dan zfs tidak fleksibel untuk memungkinkan membentuk kembali seperti itu. Karena bagaimanapun saya membangun kembali, saya mengunjungi kembali mdadm.
BeowulfNode42
Anda beruntung dengan RAID5 / 6 sejauh ini. Faktanya adalah, ini tahun 2013 dan RAID masih mengalami lubang tulis. Jika Anda kehilangan daya setelah data ditulis tetapi sebelum paritas ditulis maka Anda baru saja merusak data bagus Anda dan mungkin dengan inkonsistensi array Anda juga terpanggang. Terima kasih RAID5.
bahamat
Masalahnya, apa yang ingin Anda lakukan sebaiknya dilakukan pada lapisan sistem file. Kalau tidak, Anda perlu beberapa cara untuk mendeteksi dan lebih baik mengoreksi bit busuk, mungkin dalam situasi redundansi atau tidak, dan RAID tidak cocok untuk itu. Tidak hanya tidak ada jaminan bahwa Anda tidak akan berakhir dengan bit busuk pula (bagaimana jika satu drive gagal dan yang lain membaca bit salah dari platter?), Tetapi RAID biasa juga tidak memiliki konsep tentang apa yang penting data dan apa yang hanya kebisingan. Karena ZFS hanya menggosok data yang direferensikan , bit busuk pada bagian disk yang tidak digunakan menjadi masalah.
CVn
Sungguh, Anda tidak bisa mengharapkan meletakan sistem file acak di atas beberapa disk (bahkan dengan redundansi) untuk tiba-tiba melindungi Anda terhadap kesalahan penyimpanan. Saya tidak pada perang suci untuk membawa ZFS ke massa (meskipun saya pikir itu adalah penemuan yang hebat, dan menggunakannya sendiri di Linux untuk dasarnya semua kecuali partisi root, yang ext4 pada mdraid1 untuk kompatibilitas perangkat lunak), tetapi Saya juga mengakui bahwa masalah Anda adalah salah satu masalah yang ZFS dirancang dari bawah ke atas untuk menyelesaikan: deteksi yang terjamin dan jika mungkin memperbaiki kerusakan data tanpa mempedulikan penyebabnya.
CVn
Saya pikir Anda harus merevisi kebutuhan Anda. Apakah Anda benar-benar membutuhkan perlindungan bitrot bahkan untuk kasus ketika koreksi kesalahan diterapkan? Apakah Anda tahu betapa tidak mungkinnya bagi bitrot untuk DIBERIKAN bahwa itu juga dikoreksi oleh disk ECC?
manusia gua

Jawaban:

5

Terus terang, saya merasa agak mengejutkan bahwa Anda akan menolak RAIDZ2 ZFS. Tampaknya sesuai dengan kebutuhan Anda hampir dengan sempurna, kecuali kenyataan bahwa itu bukan Linux MD. Saya tidak pada perang salib untuk membawa ZFS ke massa, tetapi fakta sederhana adalah bahwa Anda adalah salah satu jenis masalah yang ZFS dirancang dari bawah ke atas untuk dipecahkan. Mengandalkan RAID (RAID "biasa") apa pun untuk memberikan deteksi dan koreksi kesalahan yang mungkin dalam situasi pengurangan atau tidak ada redundansi tampaknya berisiko. Bahkan dalam situasi di mana ZFS tidak dapat memperbaiki kesalahan data dengan benar, setidaknya dapat mendeteksi kesalahan dan membiarkan Anda tahu bahwa ada masalah, yang memungkinkan Anda untuk mengambil tindakan korektif.

Anda tidak harus melakukan scrub penuh reguler dengan ZFS, meskipun disarankan untuk berlatih. ZFS akan memverifikasi bahwa data yang dibaca dari disk cocok dengan apa yang ditulis sebagai data yang sedang dibaca, dan dalam kasus ketidakcocokan baik (a) menggunakan redundansi untuk merekonstruksi data asli, atau (b) melaporkan kesalahan I / O kepada aplikasi. Juga, menggosok adalah operasi online prioritas rendah, sangat berbeda dari pemeriksaan sistem file di sebagian besar sistem file yang dapat prioritas tinggi dan offline. Jika Anda menjalankan scrub dan sesuatu selain yang ingin dilakukan I / O, scrub akan mengambil kursi belakang selama durasi. Scrub ZFS menggantikan scrub RAID dan metadata dan data sistem file pemeriksaan integritas, jadi jauh lebih menyeluruh daripada hanya menggosok array RAID untuk mendeteksi bit busuk (yang tidak memberi tahu Anda jika data masuk akal sama sekali, hanya saja itu telah ditulis dengan benar oleh pengontrol RAID).

Redundansi ZFS (RAIDZ, mirroring, ...) memiliki keuntungan bahwa lokasi disk yang tidak digunakan tidak perlu diperiksa konsistensi selama scrub; hanya data aktual yang diperiksa selama scrub, saat alat berjalan di rantai blok alokasi. Ini sama dengan kolam non-redundan. Untuk RAID "biasa", semua data (termasuk lokasi yang tidak digunakan pada disk) harus diperiksa karena pengontrol RAID (apakah perangkat keras atau perangkat lunak) tidak tahu data apa yang sebenarnya relevan.

Dengan menggunakan RAIDZ2 vdevs, setiap dua drive konstituen dapat gagal sebelum Anda berisiko kehilangan data aktual dari kegagalan drive lain, karena Anda memiliki redundansi senilai dua drive. Ini pada dasarnya sama dengan RAID6.

Di ZFS semua data, baik data pengguna dan metadata, adalah checksummed (kecuali jika Anda memilih untuk tidak melakukannya, tetapi itu direkomendasikan terhadap), dan checksum ini digunakan untuk mengonfirmasi bahwa data tidak berubah karena alasan apa pun. Sekali lagi, jika sebuah checksum tidak sesuai dengan nilai yang diharapkan, data akan direkonstruksi secara transparan atau kesalahan I / O akan dilaporkan. Jika kesalahan I / O dilaporkan, atau scrub mengidentifikasi file dengan korupsi, Anda akan mengetahui fakta bahwa data dalam file tersebut berpotensi rusak dan dapat memulihkan file tertentu dari cadangan; tidak perlu untuk mengembalikan array penuh.

RAID, bahkan paritas ganda, RAID tidak melindungi Anda terhadap situasi seperti misalnya ketika satu drive gagal dan satu lagi membaca data dengan tidak benar dari disk. Misalkan satu drive gagal dan ada sedikit flip di mana saja dari salah satu drive lain: tiba-tiba, Anda memiliki korupsi yang tidak terdeteksi, dan kecuali Anda senang dengan itu Anda akan memerlukan cara untuk setidaknya mendeteksinya. Cara untuk mengurangi risiko itu adalah dengan memeriksa setiap blok pada disk dan memastikan checksum tersebut tidak dapat rusak bersama dengan data (melindungi terhadap kesalahan seperti penulisan lalat, menulis yatim, menulis ke lokasi yang salah pada disk, dll.), Yang persis apa yang dilakukan ZFS selama checksumming diaktifkan.

Satu-satunya downside nyata adalah bahwa Anda tidak dapat dengan mudah mengembangkan vdev RAIDZ dengan menambahkan perangkat ke dalamnya. Ada solusi untuk itu, biasanya melibatkan hal-hal seperti file jarang sebagai perangkat dalam vdev, dan sangat sering disebut "Saya tidak akan melakukan ini jika itu data saya". Oleh karena itu, jika Anda menggunakan rute RAIDZ (terlepas dari apakah Anda menggunakan RAIDZ, RAIDZ2 atau RAIDZ3), Anda harus memutuskan di muka berapa banyak drive yang Anda inginkan di setiap vdev. Meskipun jumlah drive di vdev sudah diperbaiki, Anda dapat menumbuhkan vdev secara bertahap (memastikan untuk tetap dalam ambang redundansi vdev) mengganti drive dengan yang berkapasitas lebih besar dan memungkinkan resilver lengkap.

sebuah CVn
sumber
5
Dalam pertanyaan awal saya, saya mencoba untuk menghindari argumen zfs vs raid karena ada banyak info tentang itu. Saya ingin info spesifik tentang mdadm. Juga karena saya tidak akan membaca semua data cukup sering untuk memastikan bahwa data digosok secara teratur, saya perlu memaksa scrub array penuh secara teratur terlepas dari zfs atau raid.
BeowulfNode42
@ BeowulfNode42 secara pribadi saya sarankan menggunakan checksum layer aplikasi untuk data yang sangat penting (mis. Gunakan sha256 untuk checksum data penting Anda). ZFS dapat melakukan ini per blok yang menurut saya benar-benar berlebihan. Saya pikir ini menjelaskan mengapa tidak banyak sistem file checksum blok mereka seperti ZFS tidak karena IMO ini lebih merupakan masalah lapisan aplikasi dalam pandangan saya.
manusia gua
1
@ penjaga saya tidak tahu tentang Anda; Saya sangat menyukai kenyataan bahwa saya tidak harus terus-menerus memeriksa file hanya untuk memastikan bahwa mereka belum rusak. Tentu, sebagian besar waktu tidak ada korupsi , dalam hal ini tidak ada salahnya dilakukan (dengan ZFS, Anda mendapatkan algoritma checksum pilihan Anda di antara segelintir, sehingga Anda dapat memilih titik pilihan Anda sepanjang kontinum keamanan / kinerja), tetapi checksum tingkat sistem file otomatis menjamin bahwa tidak ada korupsi yang tidak dikoreksi karena jika ada, Anda akan mengetahuinya, dalam kasus ZFS dengan menerima kesalahan I / O alih-alih data yang rusak.
CVn
@ MichaelKjörling tidak, itu tidak "menjamin" (hanya mengurangi kemungkinan kesalahan tidak terdeteksi relatif terhadap pemeriksaan hanya disk, dengan jumlah yang belum ada yang dikuantifikasi! Oleh karena itu tidak ada yang benar-benar tahu betapa berguna checksuming ZFS :)), plus Anda dapat menggunakan pembungkus sederhana "baca" dan "tulis" yang secara transparan melakukan pemeriksaan untuk Anda. Orang tidak perlu memasukkan hal mewah ini ke dalam ruang kernel.
manusia gua
3
@caveman no, zfs tidak pada topik. Juga tidak mungkin implementasi RAID yang bukan mdadm. Saya ingin tahu tentang mdadm. Saya sudah memilih jawaban ini sebanyak yang saya bisa dan komentar Anda tentang jawaban di luar topik yang mengisi lebih banyak informasi tentang jawaban di luar topik tidak membantu dengan pertanyaan awal.
BeowulfNode42
3

Jawaban ini adalah produk penalaran berdasarkan berbagai bukti yang saya temukan. Saya tidak tahu bagaimana implementasi kernel Linux bekerja, karena saya bukan dev kernel dan tampaknya ada banyak informasi yang salah masuk akal di luar sana. Saya berasumsi bahwa kernel Linux membuat pilihan yang waras. Jawaban saya harus berlaku kecuali saya salah.

Banyak drive menggunakan ECC (kode koreksi kesalahan) untuk mendeteksi kesalahan baca. Jika data rusak, kernel akan menerima URE (kesalahan baca yang tidak dapat dipulihkan) untuk blok itu dari drive pendukung ECC. Dalam keadaan ini (dan ada pengecualian di bawah ini), menyalin data yang rusak, atau kosong, atas data yang baik akan menjadi gila. Dalam situasi ini kernel harus mengetahui data mana yang baik dan mana yang merupakan data buruk. Menurut artikel Ini adalah 2010 dan RAID5 masih berfungsi ... :

Pertimbangkan alternatif ini, yang saya tahu harus digunakan oleh setidaknya beberapa vendor array. Ketika sebuah drive dalam volume RAID melaporkan URE, pengontrol array menambah hitungan dan memenuhi I / O dengan membangun kembali blok dari paritas. Kemudian melakukan penulisan ulang pada disk yang melaporkan URE (berpotensi dengan verifikasi) dan jika sektor ini buruk, mikrokode akan memetakan kembali dan semuanya akan baik-baik saja.

Namun, sekarang sebagai pengecualian: jika drive tidak mendukung ECC, drive berbohong tentang korupsi data, atau firmware sangat tidak berfungsi, maka URE mungkin tidak dilaporkan, dan data yang rusak akan diberikan ke kernel. Dalam kasus ketidakcocokan data: tampaknya jika Anda menggunakan 2 disk RAID1, atau RAID5, maka kernel tidak dapat mengetahui data mana yang benar, bahkan ketika dalam keadaan tidak terdegradasi, karena hanya ada satu paritas memblokir dan tidak ada URE yang dilaporkan. Dalam disk1 RAID1 3 atau RAID6, satu blok yang ditandai non-URE yang rusak tidak akan cocok dengan paritas redundan (dalam kombinasi dengan blok terkait lainnya), sehingga pemulihan otomatis yang tepat harus dimungkinkan.

Moral dari cerita ini adalah: gunakan drive dengan ECC. Sayangnya tidak semua drive yang mendukung ECC mengiklankan fitur ini. Di sisi lain, berhati-hatilah: Saya kenal seseorang yang menggunakan SSD murah dalam 2 disk RAID1 (atau 2 copy RAID10). Salah satu drive mengembalikan data acak yang rusak pada setiap pembacaan sektor tertentu. Data yang rusak disalin secara otomatis ke data yang benar. Jika SSD menggunakan ECC, dan berfungsi dengan baik, maka kernel seharusnya mengambil tindakan korektif yang tepat.

sudoman
sumber
1
Saya pikir semua HDD modern memiliki beberapa bentuk ECC internal. Apakah itu efektif, benar, atau tidak berfungsi adalah masalah lain. ECC harus digunakan secara internal di drive untuk dapat melaporkan URE. Membusuk sedikit diam, yang paling saya minati, tidak melaporkan URE bahkan pada drive yang mendukungnya, karena mereka pikir mereka memiliki data yang benar, ketika mereka tidak.
BeowulfNode42
Dengan bit busuk, saya berasumsi maksud Anda bit membalik secara acak. Bagaimanapun ECC dirancang untuk mendeteksi bit yang terbalik. Menurut Wikipedia, koreksi kesalahan Reed – Solomon adalah format ECC yang umum ditemukan pada tahun 1960 dan masih digunakan dalam disk Blu-Ray + HDD. Jika Anda menemukan bahwa algoritma itu sangat andal, maka pertanyaan Anda seharusnya cukup banyak dijawab, karena perangkat keras modern yang layak, menurut definisi, sama baiknya, jika tidak lebih baik, bahkan jika Anda tidak tahu sepotong kesopanan perangkat keras hanya dengan melihatnya.
sudoman
1
Busuk bit juga dapat terjadi karena masalah lain seperti ketika beberapa masalah menyebabkan kepala drive tidak disejajarkan dengan benar ke tempat yang menurutnya sedang ditulis dan tumpah ke sektor terdekat. Mungkin memperbaiki sektor yang ingin dikerjakannya, tetapi sektor terdekat akan rusak. Jika kebetulan telah menulis data + ecc sedemikian rupa sehingga ECC untuk laporan sektor terdekat baik-baik saja maka drive tidak akan pernah tahu ia memiliki masalah. Jauh lebih mungkin, beberapa perangkat lunak jahat memerintahkan drive untuk menulis data buruk, hdd akan dengan setia menyimpan data buruk itu. mis. perintah dd buruk
BeowulfNode42
2

Untuk perlindungan yang Anda inginkan, saya akan menggunakan RAID6 + cadangan luar biasa di 2 lokasi.

Saya pribadi menggosok seminggu sekali, dan cadangan setiap malam, mingguan dan bulanan tergantung pada data penting dan kecepatan perubahan.

djsmiley2k dalam kegelapan
sumber
1
tetapi kemampuan deteksi / koreksi bit busuk apa yang ditawarkan?
BeowulfNode42
1
RAID6 dengan scrubbing sering menawarkan perlindungan bit-rot, karena paritas ganda secara efektif membuat tiga versi dari blok yang sama, sehingga "voting" dapat diadakan pada versi mana yang benar. AFAIK, penggosokan RAID6 di linux dm-raid tidak hanya itu, tolong perbaiki saya jika saya salah.
P.Péter
1
@ P.Péter Saya menyadari bahwa matematika yang terlibat BISA menggunakan sistem pemungutan suara, tetapi apakah mdadm? Apakah Anda tahu ada dokumentasi tentang ini atau memiliki pengalaman pribadi yang telah mengarahkan Anda ke kesimpulan ini. Terutama mengingat jawaban Ethan.
BeowulfNode42
Ini beberapa waktu yang lalu, tapi saya samar-samar ingat membaca mekanisme mdadm RAID6 sebelum berkomentar. Maaf, tidak terlalu spesifik. :( Saya kira kita bisa menggunakan ahli nyata tentang mdadm ...
P.Péter
2

Saya tidak punya cukup perwakilan untuk berkomentar, tetapi saya ingin menunjukkan bahwa sistem mdadm di Linux TIDAK memperbaiki kesalahan. Jika Anda mengatakannya untuk "memperbaiki" kesalahan selama scrub, katakanlah, RAID6, jika ada ketidakkonsistenan, itu akan "memperbaikinya" dengan mengasumsikan bagian data benar dan menghitung ulang paritas.

Ethan
sumber
1
Ini sepertinya tidak mungkin, kecuali saya salah paham dengan Anda. Apakah maksud Anda bahwa data dari blok yang rusak sering disalin dari blok yang benar? Ini akan mengharuskan blok buruk tersebut tidak berasal dari drive yang mendukung ECC (dan karenanya tidak akan melaporkan URE), dan bahwa Anda menggunakan RAID5 atau 2 salin RAID1 (bukan RAID6 seperti yang Anda sarankan.)
sudoman
@sudoman, selama scrub, jika subsistem Linux MD mendeteksi ketidakcocokan antara data dan paritas, ia secara membuta mengasumsikan bahwa paritas salah dan menulis ulang berdasarkan data. Dimungkinkan untuk menggunakan paritas ganda dari RAID 6 untuk mencari tahu mana yang salah, tetapi subsistem Linux MD tidak melakukan ini.
Tandai
1
Ethan, saya kira Anda tidak memiliki referensi untuk informasi ini? atau contoh pengalaman pribadi yang ingin Anda bagikan? Mengingat tumbleweed yang dihasilkan Q ini, bahkan info anekdotal akan sangat membantu. Karena Q ini diposting, saya punya beberapa masalah dengan mdadm RAID1 untuk boot drive, pada USB stick (murah) ketika salah satunya rusak. Beberapa penyelidikan kemudian menunjukkan bahwa usb stick yang gagal tidak memiliki cukup atau ada pengecekan kesalahan, atau itu hanya gagal untuk menulis data ke beberapa blok dan tidak menghasilkan kesalahan tulis. Saya harus menginstal ulang OS.
BeowulfNode42
-2

sedikit busuk fud.? Tentu...

Saya kira Anda perlu berbicara dengan SEAGATE. (lupa? Apakah itu alasannya)? drive sekarang semua memiliki koreksi ECC 100bit Anda harus membuktikan busuk pertama.
Saya yakin Anda tidak bisa. (Ini hal yang FUD untuk dikhawatirkan, bukan?) seperti takut pada hantu atau yang ke-13? dan tidak dilakukan di sini. tidak ada bukti yang terjadi. dan lebih buruk tidak ada bukti penyebabnya.

Pertama, tentukan apa arti bit busuk.? Aduh ... HDD: ECC memeriksa data (bahkan 1 bit) terhadap penyimpanan ECC 100 bit. jika salah, itu memperbaikinya, jika terus gagal mesin SMART, pasti pada drive SAS, itu secara logis menggantikan cluster atau sektor dengan yang baik. menggunakan cluster cadangan. ini memperbaiki kerusakan. Ya semua drive menumbuhkan bit buruk dari hari pertama hingga akhir, dari drive pertama IBM ke SEKARANG. tapi sekarang kami melakukan perbaikan sendiri, Baca laporan lengkap Seagate. tak ada habisnya, dan belajar bagaimana drive bekerja. baik?

ini terus berlangsung sampai Anda kehabisan suku cadang, (otak hdd, pintar) dan kemudian SMART menjerit AKHIR HIDUP. (atau bahkan lebih awal, seperti HP) pada pengontrol HP P420, ia mengawasi ini setiap saat. Milik saya email saya, menunjukkan DEKAT DARI cluster SPARE. Kadang-kadang suku cadang melaju lebih cepat, pertanda pasti akan segera berakhir, (10 tahun juga, kurang di sata rongsokan.

Saya memanggil BOGUS, dan FUD pada bit busuk.

Dugaan saya adalah seseorang yang membuat PC salah menuliskan data, untuk alasan apa pun. tidak menjalankan memori ECC ?? oops, server sebenarnya memiliki ECC RAM. terinfeksi virus.? atau kehilangan daya selama penulisan (tidak ada UPS>?)? atau memiliki memori buruk.? atau ESD rusak. Atau PSU membuat banyak kebisingan (buruk)

Saya memanggil FUD di sini. Maaf,

savvy2
sumber
1
Saya baru saja mengklarifikasi bahwa saya berbicara tentang sistem rumah saya, jadi ECC dan perangkat keras tingkat server berada di luar kisaran harga anggaran saya. Laboratorium rumah saya jauh lebih rentan terhadap kehilangan daya yang tidak terduga bahkan dengan mini up-nya, atau peristiwa acak lainnya, seperti menara yang jatuh atau sesuatu. Ada banyak cara lain agar HDD diberitahu untuk menyimpan data yang salah dan meminta HDD menyimpan bit ECC untuk data yang salah. Saya tidak peduli bagaimana kesalahan terjadi, saya ingin mereka mudah diperbaiki.
BeowulfNode42