Keamanan cache tulis pada drive SATA dengan hambatan

Saya telah membaca akhir-akhir ini tentang menulis caching, NCQ, bug firmware, hambatan, dll tentang drive SATA, dan saya tidak yakin apa pengaturan terbaik yang akan membuat data saya aman jika terjadi kegagalan daya.

Dari apa yang saya pahami, NCQ memungkinkan drive untuk menyusun ulang penulisan untuk mengoptimalkan kinerja, sambil tetap memberi tahu kernel tentang permintaan yang telah ditulis secara fisik.

Cache tulis membuat drive melayani permintaan lebih cepat, karena tidak menunggu data ditulis ke disk fisik.

Saya tidak yakin bagaimana campuran NCQ dan Write cache di sini ...

Filesystem, khususnya yang dijurnal, perlu memastikan kapan permintaan tertentu telah ditulis. Juga, proses ruang pengguna menggunakan fsync () untuk memaksa flush file tertentu. Panggilan ke fsync () tidak boleh kembali sampai sistem file yakin bahwa data ditulis ke disk.

Ada fitur (FUA, Force Unit Access), yang saya lihat hanya pada drive SAS, yang memaksa drive untuk mem-bypass cache dan menulis langsung ke disk. Untuk semua yang lain, ada hambatan penulisan, yang merupakan mekanisme yang disediakan oleh kernel yang dapat memicu flush cache pada drive. Ini memaksa semua cache untuk ditulis, bukan hanya data penting, sehingga memperlambat seluruh sistem jika disalahgunakan, dengan fsync () misalnya.

Kemudian ada drive dengan bug firmware, atau yang sengaja berbohong tentang kapan data telah ditulis secara fisik.

Setelah mengatakan ini .. ada beberapa cara untuk mensetup drive / filesystems: A) NCQ dan Write cache dinonaktifkan B) Hanya NCQ diaktifkan C) Hanya Write cache diaktifkan D) Baik NCQ dan cache tulis diaktifkan

Saya berasumsi hambatan diaktifkan .. BTW, bagaimana cara memeriksa apakah mereka benar-benar diaktifkan?

Dalam hal kehilangan daya, saat secara aktif menulis ke disk, tebakan saya adalah bahwa opsi B (NCQ, tanpa cache) aman, baik untuk jurnal sistem data dan data. Mungkin ada penalti kinerja.

Opsi D (NCQ + cache), jika menggunakan hambatan atau FUA, akan aman untuk jurnal sistem file dan aplikasi yang menggunakan fsync (). Akan buruk untuk data yang menunggu di cache, dan terserah sistem file untuk mendeteksinya (checksum), dan setidaknya sistem file tidak akan (semoga) dalam keadaan tidak stabil. Dari segi kinerja, seharusnya lebih baik.

Namun pertanyaan saya adalah ... Apakah saya kehilangan sesuatu? Apakah ada variabel lain yang perlu dipertimbangkan? Apakah ada alat yang dapat mengkonfirmasi ini, dan drive saya berperilaku sebagaimana mestinya?

Untuk sistem Enterprise yang lurus, ada lapisan tambahan dalam bentuk adaptor penyimpanan (hampir selalu berupa kartu RAID) tempat lapisan cache lainnya ada. Ada banyak abstraksi dalam penyimpanan tumpukan hari ini, dan aku pergi ke detail jauh di ini dalam serangkaian blog saya lakukan pada Tahu Anda I / O .

Kartu RAID dapat mem-bypass cache pada disk, beberapa di antaranya bahkan memungkinkan untuk mengaktifkan fitur ini di RAID BIOS. Ini adalah salah satu alasan mengapa disk Enterprise adalah Enterprise, firmware mereka memungkinkan hal-hal yang drive konsumen ( terutama drive 'hijau') tidak. Fitur ini secara langsung membahas kasus yang Anda khawatirkan: kegagalan daya dengan tulisan yang tidak terhubung. Cache kartu RAID, yang harus berupa baterai atau yang didukung flash, akan dipertahankan hingga daya kembali dan penulisan itu dapat diterima kembali.

SSD perusahaan tertentu termasuk kapasitor onboard dengan semangat yang cukup untuk melakukan cache onboard, sebelum dimatikan sepenuhnya.

Jika Anda bekerja dengan sistem dengan disk yang terhubung langsung ke motherboard, ada lebih sedikit jaminan. Kecuali jika disk itu sendiri memiliki kemampuan untuk melakukan cache-tulis, kegagalan daya memang akan menyebabkan kerugian. The xfs filesystem mendapatkan reputasi untuk tidak dapat diandalkan karena ketidakmampuan itu untuk bertahan hidup hanya modus kegagalan ini; itu dirancang untuk berjalan pada sistem perusahaan penuh dengan ketahanan penyimpanan yang direkayasa.

Namun, waktu telah berjalan dan XFS telah direkayasa untuk bertahan hidup ini. Sistem file Linux utama lainnya (serta ntfs di Windows) sudah memiliki rekayasa untuk bertahan dari mode kegagalan ini. Bagaimana seharusnya bekerja adalah bahwa tulisan yang hilang tidak akan muncul di jurnal FS dan itu akan tahu mereka tidak berkomitmen, sehingga korupsi akan terdeteksi dan bekerja dengan aman.

Anda menunjuk satu masalah di sini: firmware disk yang terletak. Dalam hal ini jurnal FS akan membuat asumsi yang salah versus kenyataan dan korupsi mungkin tidak terdeteksi untuk beberapa waktu. Parity RAID dan mirror RAID dapat mengatasi masalah ini karena harus ada salinan lain yang harus dikirim. Tetapi pengaturan disk tunggal tidak akan memiliki pemeriksaan silang, sehingga akan benar-benar kesalahan.

Anda menyiasati risiko firmware dengan menggunakan drive tingkat Perusahaan yang mendapatkan lebih banyak validasi (dan diuji versus pola beban kerja Anda yang diduga), dan merancang sistem penyimpanan Anda sehingga dapat bertahan dari ketidakbenaran seperti itu.

Jurnal filesystem awalnya menunggu penulisan untuk jurnal selesai sebelum menerbitkan menulis ke metadata, dengan asumsi bahwa tidak ada cache tulis drive. Dengan drive caching diaktifkan, asumsi ini rusak dan dapat menyebabkan hilangnya data. Dengan demikian, hambatan diciptakan. Dengan penghalang, jurnal dapat memastikan bahwa penulisan ke jurnal selesai sebelum menulis ke metadata, bahkan jika disk menggunakan cache tulis. Pada lapisan pengandar disk, penghalang memaksa flush cache disk sebelum IO berikutnya diturunkan, ketika drive melaporkan bahwa ia memiliki cache tulis dan diaktifkan. Kalau tidak, ini tidak diperlukan, jadi penghalang hanya mencegah penerbitan IO berikutnya ke drive sampai IO sebelumnya telah selesai. NCQ hanya berarti harus menunggu lebih dari satu permintaan yang tertunda untuk diselesaikan sebelum mengeluarkan lebih banyak.