Disk SATA yang menangani caching tulis dengan benar?

Sangat umum untuk melihat saran untuk menonaktifkan cache tulis pada disk individual yang digunakan untuk basis data karena jika tidak, beberapa disk akan mengakui penulisan yang belum sampai ke permukaan disk.

Ini menyiratkan bahwa beberapa disk tidak mengakui penulisan sampai mereka telah sampai ke permukaan disk (Perbarui: atau bahwa mereka melaporkan secara akurat ketika diminta untuk membersihkan cache. Di mana saya dapat menemukan disk tersebut, atau di mana saya dapat mencari informasi yang berwenang di mana menemukan disk tersebut?

Saya menyiapkan beberapa server DB yang benar-benar akan mendapat manfaat dari menggunakan cache tulis, tetapi aplikasi ini sensitif terhadap harga dan saya lebih suka tidak menggandakan biaya subsistem disk saya untuk beberapa pengontrol RAID caching karena saya tidak memiliki informasi yang cukup untuk tahu apakah saya bisa mempercayai cache di setiap drive.

Secara umum, sebagai jawaban langsung untuk pertanyaan Anda, saya tidak mengetahui adanya merek utama drive SATA yang drive itu sendiri memiliki bug relatif terhadap operasi yang tepat dengan caching diaktifkan. Yaitu, dari perspektif drive saja, drive melakukan apa yang seharusnya dilakukan dari perspektif caching. Saya juga akan mencatat bahwa bahkan ketika menulis caching yang diaktifkan, bahwa penundaan dari disk menulis di kabel SATA ke media berputar secara fisik yang diperbarui masih sangat singkat (~ 50 sampai 100ms biasanya). Ini tidak seperti data cache kotor akan hanya duduk di sana selama beberapa detik ..... drive terus mencoba untuk mendapatkan data kotor dari cacheke media fisik secepat mungkin. Ini bukan hanya masalah keamanan data, tetapi salah satu dari siap untuk menerima penulisan di masa depan tanpa penundaan (yaitu: menulis posting).

Masalah yang muncul ketika caching diaktifkan adalah bahwa urutan penulisan ke drive melalui kabel SATA dan urutan penulisan ke media putar tidak sama. Ini tidak pernah dapat menyebabkan masalah KECUALI Anda kehilangan daya atau kerusakan sistem sebelum semua konten cache masuk ke disk. Mengapa? ->

Masalah yang dapat muncul di sini adalah relatif terhadap kekokohan transaksi dari sistem file dan / atau isi file database untuk penulisan yang rusak. Akibatnya, mereka yang berpotensi kehilangan aturan menulis secara teoritis dapat merusak integritas logika transaksi yang seharusnya dijamin oleh disk menulis yang terjadi dalam urutan yang sangat spesifik kepada media.

Sekarang, tentu saja, para perancang sistem file, basis data, pengontrol RAID, dll. Menyadari (atau tentunya harus sadar) tentang fenomena ini relatif terhadap penulisan caching. Tembolok tulis sangat diinginkan dari sudut pandang kinerja di sebagian besar skenario tipe I / O akses acak. Faktanya, menyediakan caching tulis adalah elemen kunci untuk dapat memiliki manfaat nyata bagi Antrian Perintah Asli ( NCQ) yang lebih canggih) yang didukung pada SATA yang lebih baru dan beberapa generasi terakhir implementasi PATA. Jadi, untuk menjamin pesanan ke media fisik pada saat-saat kritis tertentu, sistem file dan / atau aplikasi, dll. Secara khusus dapat meminta flush dari cache tulis ke media. Pada penyelesaian permintaan sinkronisasi ini - semua yang tertunda dari (berpotensi) buffer file, cache disk OS, cache disk fisik dll. Sebenarnya keluar pada media sesuai desain sistem transaksi pada operasi kritis yang tepat. Artinya, ini terjadi dengan benar jika pemrogram membuat panggilan yang tepat di bagian atas DAN setiap elemen dari rangkaian perangkat lunak dan perangkat keras ini melakukan tugasnya dengan benar. yaitu: Tidak ada bug dalam hal ini di drive, pengontrol RAID, driver disk, cache OS, sistem file, mesin database, dll. Ini adalah banyak perangkat lunak yang semuanya harus berfungsi dengan benar. Selain itu, memverifikasi kebenaran dalam hal ini sangat sulit karena dalam hampir semua situasi biasanya urutan penulisan tidak masalah sama sekali .... dan kegagalan daya dan skenario kerusakan adalah tes sulit untuk dibangun. Jadi, pada akhirnya "mematikan cache tulis" pada satu atau lebih dari berbagai lapisan dan / atau makna istilah ini .... memiliki reputasi "memperbaiki" jenis masalah tertentu. Akibatnya, mematikan perilaku cache tulis dari pengontrol RAID atau Cache Disk OS, atau Drive, dll. Adalah menghindari satu atau lebih bug dalam sistem ..... dan sumber pengetahuan tersebut. dan kegagalan daya dan skenario kerusakan adalah tes sulit untuk dibangun. Jadi, pada akhirnya "mematikan cache tulis" pada satu atau lebih dari berbagai lapisan dan / atau makna istilah ini .... memiliki reputasi "memperbaiki" jenis masalah tertentu. Akibatnya, mematikan perilaku cache tulis dari pengontrol RAID atau Cache Disk OS, atau Drive, dll. Adalah menghindari satu atau lebih bug dalam sistem ..... dan sumber pengetahuan tersebut. dan kegagalan daya dan skenario kerusakan adalah tes sulit untuk dibangun. Jadi, pada akhirnya "mematikan cache tulis" pada satu atau lebih dari berbagai lapisan dan / atau makna istilah ini .... memiliki reputasi "memperbaiki" jenis masalah tertentu. Akibatnya, mematikan perilaku cache tulis dari pengontrol RAID atau Cache Disk OS, atau Drive, dll. Adalah menghindari satu atau lebih bug dalam sistem ..... dan sumber pengetahuan tersebut.

Bagaimanapun, kembali ke inti pertanyaan: Di bawah SATA, penanganan spesifik semua perintah baca / tulis disk dan perintah cache flush didefinisikan dengan baik oleh spesifikasi SATA . Selain itu, produsen drive harus memiliki dokumentasi terperinci untuk setiap model drive atau keluarga drive yang menggambarkan penerapannya dan kepatuhan terhadap aturan ini seperti contoh ini untuk Seagate Barracuda drive . Khususnya, lihat detail FITUR SET SATAperintah yang mengontrol mode operasional drive dan secara khusus opsi 82h dapat digunakan untuk menonaktifkan caching disk pada level drive karena defaultnya adalah caching tulis diaktifkan pada semua drive yang saya ketahui. Jika Anda benar-benar ingin menonaktifkan cache, perintah ini harus dilakukan pada awal setiap drive reset atau power up dan biasanya di bawah kendali driver disk untuk sistem operasi Anda. Anda mungkin dapat mendorong driver OS Anda untuk mengatur mode ini melalui IOCTL dan / atau tipe Pengaturan Registri, tetapi ini sangat bervariasi.

Sudah pengalaman saya bahwa controller disk caching yang didukung baterai akan menonaktifkan cache di drive. Saya tidak mengetahui cara untuk menonaktifkan cache pada disk sebaliknya. Bahkan jika Anda dapat menonaktifkan cache di-disk, kinerja akan sangat menderita.

Untuk optoin berbiaya rendah, Anda dapat menggunakan UPS murah yang dapat memberi sinyal sistem Anda untuk shutdown yang teratur.

Saya menggunakan sistem RAID dengan supercapacitor daripada baterai untuk mempertahankan cache. Baterai aus, harus dipantau, harus diganti dan menunjukkan titik kegagalan potensial dalam hal tersebut. Kapasitor mengisi daya pada saat startup, membersihkan cache ketika daya dari UPS gagal, bertahan hampir selamanya, tidak memerlukan pemantauan, dll. Namun, kecuali Anda menjalankan bisnis di garis kemiskinan (tidak jarang hari ini) Anda harus memiliki UPS dan perangkat lunak yang mematikan sistem dengan bersih pada kegagalan - Saya biasanya memberikannya 5-15 menit (tergantung pada beban UPS dan oleh karena itu baterai tersedia) sebelum shutdown jika daya kembali menyala.

Selama badai, Anda mungkin (atau mungkin memiliki - sistem daya menjadi lebih baik) melihat lampu berkedip, kadang-kadang sebelum mereka padam. Ini adalah perangkat yang disebut recloser. Itu adalah pemutus sirkuit yang ketika tersandung mencoba untuk menutup sakelar yang terbuka seandainya kelebihan beban bersifat sementara, yang kebanyakan adalah. Jika gagal untuk tetap tertutup setelah, katakan tiga kali mencoba, itu tetap terbuka. Pria malang itu harus keluar dalam hujan dan menghadapinya. Jangan merasa kasihan padanya, sementara hanya membuat dua kali apa yang Anda dan saya lakukan dan dua kali bahwa jika lembur, itu pekerjaan yang berbahaya.

Salah satu kesalahpahaman jika disk menulis kembali cache adalah bahwa mereka hanya kehilangan data daya yang hilang. Ini tidak selalu terjadi, terutama pada perangkat sATA. Jika perangkat sATA memiliki kesalahan padanya (seperti bug FW kasus atau bug pengontrol) dan me-reset atau diatur ulang secara eksternal, tidak ada jaminan bahwa data dalam cache write-back masih tersedia setelah hang.

Ini dapat menyebabkan skenario di mana perangkat memiliki kesalahan sementara, akan direset, kehilangan data terjadi dalam hilangnya cache kotor, dan ini diam di atas tingkat blok driver.

Lebih buruk lagi, menonaktifkan cache drive melalui alat OS juga akan hilang pada pengaturan ulang perangkat, sehingga bahkan jika perangkat memiliki cache yang dinonaktifkan pada awal hari, jika perangkat diatur ulang, itu akan mengaktifkan kembali cache tulis-kembali. Di reset lain, perangkat kemudian akan kehilangan data.

Drive SCSI / SAS dan beberapa drive sATA memiliki kemampuan untuk menyimpan status profil write-back untuk memastikan bahwa seluruh pengaturan ulang properti tidak hilang - tetapi dalam praktiknya ini jarang digunakan.

Pengontrol RAID yang mengintegrasikan lapisan blok ke dalam lapisan atas dapat melihat pengaturan ulang drive dan menonaktifkan cache tulis kembali - tetapi pengontrol sATA dan SAS standar tidak akan melakukan ini.

Batasan ini juga berlaku untuk FITUR SET lainnya dan parameter serupa yang dikonfigurasi untuk kinerja dan keandalan.

Seperti yang Anda katakan, pengontrol RAID yang didukung baterai yang benar akan mahal, tetapi Anda dapat menemukan pengontrol Dell Perc5 / i di eBay seharga £ 100 ($ 150) dan terutama dengan RAID5 kecepatan pengontrol seperti Perc5 / i akan memukau Anda. Saya memiliki beberapa server dengan perc5 / is dan enam disk array RAID5, dan mereka adalah di antara disk tercepat yang pernah saya lihat. Khusus untuk aplikasi basis data, cakram cepat akan sangat meningkatkan kinerja.

Saya akan menggigit peluru dan membeli kontroler RAID.

JR

Sejauh yang saya mengerti, fsync () faking adalah properti pengontrol RAID yang didukung baterai, bukan drive. Pengontrol RAID berisi baterai yang dapat memberi daya pada cache tulis hingga daya dipulihkan ke drive dan penulisan dapat dilakukan dengan aman ke disk. Ini memungkinkan pengontrol untuk segera kembali ke OS, karena membuat beberapa tingkat jaminan bahwa penulisan akan ditulis ke disk.

Perlu dicatat, jika cache writeback cache terisi, write akan memblokir sampai cache telah ditulis kembali ke drive. Ini berarti cache umumnya tidak seefektif di bawah menulis berkelanjutan.

Berapa banyak IOPS yang dibutuhkan aplikasi Anda? Apakah Anda yakin bahwa Anda dibatasi oleh cache tulis drive, atau bahwa kecil (dibandingkan dengan memori server Anda) pada drive akan bermanfaat?