Apa keseluruhan fungsi dan efek dari "Matikan penyangga cache tulis Windows pada perangkat"

Di Windows 7, menggunakan Device Manager, menampilkan properti disk, dan pergi ke tab Kebijakan, ada 2 item switch. Tembolok tulis, yang bukan tentang pertanyaan ini.

dan

[X] Matikan buffer write-cache Windows yang membilas perangkat <--- ini saja!

Microsoft menempatkan penafian pada tab untuk item itu. "Untuk mencegah kehilangan data, jangan pilih kotak centang ini kecuali perangkat memiliki catu daya terpisah yang memungkinkan perangkat untuk menyiram buffernya jika terjadi kehilangan daya."

Secara sederhana, apa perubahan ini untuk penulisan file, penyimpanan file, menyalin file?

1. Mengubah aksi tulis untuk program paranoid: (fakta atau fiksi)
Apakah itu mengubah cara penulisan flush bekerja untuk program yang memaksa terjadi flush cache? Beberapa program sangat ingin menyelesaikan penulisan, tanpa berspekulasi, apakah program-program ini dapat melanjutkan penulisan pelindung mereka, atau apakah ini berubah untuk program-program itu juga?

2. Jenis-jenis program yang dipengaruhi:
Apa jenis tindakan / program yang akan atau tidak akan terpengaruh oleh perubahan? Ketik, beberapa aliran program, beberapa melakukan penulisan cepat, beberapa berkelanjutan, beberapa protektif (atau jenis lain yang dapat Anda tetapkan dalam istilah sederhana).

3. Apakah Anda melihat sesuatu, atau bahkan tolok ukur:
Jika pengaturan aktif, apa saja perubahan yang dapat diamati secara tertulis? Contoh longgar dari perubahan perilaku yang diamati. atau mengamati tidak ada perubahan perilaku?

4. Apa kendala atau penundaan:
Kita tahu sebagian besar dari tindakan ini sangat cepat pada kebanyakan komputer, data akhirnya akan ditulis. Relatif dengan kecepatan drive, apakah jumlah waktu signifikan?

Untuk keperluan pertanyaan saya, risiko yang ada bukanlah salah satu pertanyaan, jika Anda ingin menutupinya, itu tidak akan menghalangi.

Apa yang dimaksud dengan "Write cache buffer flushing" hampir merupakan penipuan ini, tetapi tautannya untuk OS yang berbeda. Meskipun A memiliki beberapa info, bahkan istilah yang digunakan dalam tautan tidak sama. Itu juga tidak menjawab hal-hal paling penting yang ingin diketahui oleh pengguna, yang telah saya coba uraikan di sini.

1. Penegasan Anda dalam pertanyaan pertama adalah fiksi. Panggilan Windows API seperti masih akan memastikan bahwa data sampai ke media fisik, bahkan dengan pembilasan penulisan buffer dinonaktifkan. Jadi, program yang "aman" dan tahu apa yang mereka lakukan akan baik-baik saja. Panggilan seperti .NET, dll. Akhirnya memanggil API ini.FlushFileBuffers() FileStream.Flush()

2. Program yang melakukan banyak I / O disk tanpa menelepon FlushFileBuffers()langsung, atau API penolong apa pun yang akhirnya memanggilnya, akan melihat peningkatan kinerja yang paling nyata. Misalnya, jika Anda menjalankan I / O yang tidak penting di mana tidak masalah jika data hilang, seperti BOINC (jika hilang Anda hanya mengunduh ulang file atau mencoba menghitung ulang perhitungan), Anda dapat menghindari panggilan FlushFileBuffers(), dan panggil saja API seperti WriteFile()- data akan mendapat buffered untuk ditulis, tetapi sebenarnya tidak akan ditulis untuk waktu yang lama, seperti ketika deskriptor file ditutup, atau ketika program keluar. Sayangnya mungkin juga bahwa jika sistem crash (seperti BSOD), semua data hilang, jadi itu sangat pentingbahwa jika Anda berurusan dengan jenis data berharga / non-diganti yang Anda lakukan panggilan FlushFileBuffers(), apakah penyangga pembilasan diaktifkan atau tidak! Kalau tidak, bug driver sederhana (misalnya pada driver grafis Anda) dapat menyebabkan Anda kehilangan banyak data.

3. Tidak dapat menemukan tolok ukur apa pun, tetapi Anda akan lebih memperhatikannya dengan program yang sesuai dengan deskripsi di item kedua di atas.

4. Menyinkronkan data ke disk sebenarnya tidak secepat itu, terutama jika sering dilakukan dalam loop yang ketat. Secara default, jika saya mengingat dengan benar dari membaca buku-buku Windows Internals, NTFS secara default menyinkronkan semua buffer filesystem kotor ke disk setiap 5 detik . Ini tampaknya merupakan pertukaran yang layak antara stabilitas dan kinerja. Masalah dengan data yang sering disinkronkan adalah hal itu membuat hard drive melakukan banyak pencarian dan penulisan.

Pertimbangkan kodesemu berikut:

1: seek to a certain block (1)
2: write a couple megabytes of data into blocks starting at (1)
3: wait 2 seconds
4: seek to another block (2)
5: write some more megabytes of data into blocks starting at (2)
6: seek back to block (1)
7: write some more megabytes of data into blocks starting at (1)
8: wait 10 minutes
9: seek to block (1)
10: write some megabytes of data into blocks starting at (1)
11: wait 5 seconds
12: seek to block (2)
13: write some megabytes of data into blocks starting at (2)
14: explicit call to FlushFileBuffers()

Dengan penyiraman otomatis 5 detik aktif :

• Tulisan yang terjadi pada baris 2, 5 dan 7 terjadi pada RAM dan disk tidak bergerak, sampai 5 detik telah berlalu sejak penulisan pertama, dan kemudian data terbaru (dari baris 7) ditulis ke dalam blok (1) dan hanya data yang ditulis ke dalam blok (2) yang ditulis.
• Tulisan yang terjadi pada baris 10 dan 13, yang menimpa data dalam blok (1) dan (2), harus dituliskan ke disk lagi
• Jadi total jumlah blok yang (1) ditulis ke RAM adalah 3, dan ke disk , 2. Total jumlah blok yang (2) ditulis ke RAM adalah 2, dan ke disk , 2.

Dengan buffer 5 detik otomatis luntur (efek kotak centang dalam pertanyaan Anda):

• Tulisan yang terjadi pada baris 2, 5, 7, 10 dan 13 terjadi pada RAM dan disk tidak bergerak, sampai baris 14 dijalankan, dan kemudian data terbaru (dari baris 10 dan 13) dituliskan ke dalam blok (1) dan (2). Data lama dari baris 2, 5, dan 7 tidak pernah mengenai hard disk!

Menimbang bahwa sistem yang sibuk dapat mengalami antara ratusan hingga puluhan ribu file tulis per detik, ini bagus untuk kinerja, terutama pada hard drive pemintalan tradisional (kurang mengesankan pada SSD). RAM 20 kali lebih cepat dari hard drive sebagai ukuran umum, meskipun kesenjangannya kurang dengan SSD.

Alasan mereka mengatakan Anda harus menggunakan cadangan baterai adalah bahwa Anda tidak ingin memiliki data tertulis buffered dalam RAM selama 35 menit yang tidak ditulis ke disk hanya karena programmer Anda malas dan tidak menelepon FlushFileBuffers(), dan kemudian memiliki kegagalan daya. Tentu saja, cadangan baterai tidak melindungi Anda terhadap bug driver yang menyebabkan BSOD ....

Untuk mendukung jawaban ChatBot John Cavil , saya telah menulis sebuah program pengujian kecil:

// ...
byteEx btTest;
btTest.resize(1024*1024, 0xff); // 1MB data

CSysFile sfTest(byT("test.bin"));

swTest.Start(); // Begin timing by call `QueryPerformanceCounter` API
for (UINT i=0; i<10000; ++i) // Write 1MB data for 10000 times
{
    sfTest.SeekBegin();
    sfTest.Write(btTest); // Call `WriteFile` API 
//  sfTest.Flush();       // Call `FlushFileBuffers` API
}
swTest.Stop(); // Calculate the time-consuming start from `swTest.Start() `
// ...

Dan jalankan di Samsung 950pro NVMe disk dengan opsi "Nonaktifkan buffer cache menulis Windows pada perangkat" diaktifkan.

Hasilnya adalah:

D:\tmp> test        // without sfTest.Flush();
00:00:00.729766     // use 0.73 seconds without FlushFileBuffers()

D:\tmp> test        // with sfTest.Flush();
00:00:06.736167     // use 6.74 seconds with FlushFileBuffers()

Jadi, Anda dapat melihat FlushFileBufferspermintaan tidak dihilangkan oleh sistem (Windows tidak mengabaikan FlushFileBufferspanggilan bahkan jika opsi diaktifkan).