Qual é a função e o efeito de "Desativar a liberação do buffer de cache de gravação do Windows no dispositivo"

No Windows 7, usando o Gerenciador de dispositivos, exibindo as propriedades de um disco e indo para a guia Políticas, existem 2 itens de opção. O cache de gravação, sobre o qual esta questão não se refere.

e

[X] Desative a descarga do buffer de cache de gravação do Windows no dispositivo <--- apenas este!

A Microsoft coloca um aviso de isenção de responsabilidade na guia desse item. "Para evitar a perda de dados, não marque essa caixa de seleção, a menos que o dispositivo tenha uma fonte de alimentação separada que permita liberar seu buffer em caso de perda de energia".

Em termos simples, o que isso muda para a gravação, salvamento e cópia de arquivos?

1. Alterando ações de gravação para programas paranóicos: (fato ou ficção) Altera
a maneira como as liberações de gravação funcionam para um programa que força a liberação de cache? Alguns programas têm muita intenção de terminar a gravação, sem especular, esses programas são capazes de continuar sua gravação protetora ou isso também muda para esses programas?

2. Tipos de programas efetuados:
Quais são os tipos de ações / programas que seriam ou não seriam afetados pela mudança? Tipo, alguns programas são transmitidos, alguns fazem anotações rápidas, outros são contínuos, outros são protetores (ou qualquer outro tipo que você possa definir em termos simples).

3. Você viu alguma coisa ou até uma referência:
se a configuração estiver ativada, quais são as alterações observáveis ​​na escrita? Alguns exemplos soltos de uma mudança observada no comportamento. ou observou nenhuma mudança de comportamento?

4. Qual é o atraso ou atraso:
sabemos que a maioria dessas ações é muito rápida na maioria dos computadores. Os dados serão gravados. Em relação à velocidade da unidade, a quantidade de tempo é significativa?

Para os fins da minha pergunta, o risco que existe não é uma das perguntas; se você quiser cobri-lo, não atrapalha.

O que significa "Gravar buffer buffer flushing" significa quase uma bobagem disso, mas o link é para um sistema operacional diferente. Embora o A tenha algumas informações, mesmo o termo usado no link não é o mesmo. Também não responde às coisas mais importantes que um usuário gostaria de saber, que tentei descrever aqui.

1. Sua afirmação na primeira pergunta é ficção. API do Windows chama, como vai ainda garantir que os dados recebe todo o caminho para a mídia física, mesmo com gravação tampão rubor desativado. Portanto, programas que são "seguros" e sabem o que estão fazendo vão ficar bem. Chamadas como no .NET etc., eventualmente, chamam essa API.FlushFileBuffers() FileStream.Flush()

2. Os programas que executam muitas E / S de disco sem chamar FlushFileBuffers()diretamente, ou qualquer API auxiliar que eventualmente o chama, teriam o aumento mais notável de desempenho. Por exemplo, se você estivesse executando E / S não essencial, onde não há problema em perder dados, como o BOINC (se perder, basta baixar novamente o arquivo ou tentar calcular novamente os cálculos), evite chamar FlushFileBuffers(), e basta chamar uma API como WriteFile()- os dados serão armazenados em buffer para serem gravados, mas na verdade não serão gravados por muito tempo, como quando o descritor de arquivo estiver fechado ou quando o programa sair. Infelizmente, também é possível que, se o sistema travar (como um BSOD), todos os dados forem perdidos, o que é realmente importanteque, se você está lidando com qualquer tipo de dados valiosos / não substituíveis que você faça chamadas FlushFileBuffers(), se rubor tampão está habilitado ou não! Caso contrário, um simples bug no driver (por exemplo, no seu driver gráfico) pode causar a perda de muitos dados.

3. Não foi possível encontrar nenhum parâmetro de referência, mas você notará mais com os programas que se encaixam na descrição no segundo item acima.

4. A sincronização de dados para o disco não é tão rápida, especialmente se for feita com frequência em um loop apertado. Por padrão, se bem me lembro da leitura dos livros do Windows Internals, o NTFS sincroniza por padrão todos os buffers do sistema de arquivos sujos em disco a cada 5 segundos . Aparentemente, essa é uma troca decente entre estabilidade e desempenho. O problema com a sincronização frequente de dados é que ele faz com que o disco rígido faça muitas buscas e gravações.

Considere o seguinte pseudocódigo:

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()

Com automática de 5 segundo buffer rubor em :

• As gravações que ocorrem nas linhas 2, 5 e 7 ocorrem na RAM e o disco não se move, até decorridos 5 segundos desde a primeira gravação e, em seguida, os dados mais recentes (da linha 7) são gravados no bloco (1) e o somente dados gravados no bloco (2) são gravados.
• As gravações que ocorrem nas linhas 10 e 13, que substituem os dados nos blocos (1) e (2), precisam ser gravadas no disco novamente
• Portanto, o número total de vezes que o bloco (1) foi gravado na RAM é 3 e no disco , 2. O número total de vezes que o bloco (2) foi gravado na RAM é 2 e no disco , 2.

Com automática de 5 segundo buffer rubor off (o efeito da caixa de seleção na sua pergunta):

• As gravações que ocorrem nas linhas 2, 5, 7, 10 e 13 ocorrem na RAM e o disco não se move até a linha 14 ser executada e, em seguida, os dados mais recentes (das linhas 10 e 13) serem gravados nos blocos (1) e (2) Os dados antigos das linhas 2, 5 e 7 nunca atingem o disco rígido!

Considerando que um sistema ocupado pode experimentar entre centenas e dezenas de milhares de gravações em arquivos por segundo, isso é ótimo para desempenho, especialmente nos discos rígidos rotativos tradicionais (é menos impressionante nos SSDs). A RAM é 20 vezes mais rápida que os discos rígidos como medida geral, embora essa diferença seja menor com os SSDs.

O motivo pelo qual eles dizem que você deve usar um backup de bateria é que você não deseja ter dados gravados em buffer de 35 minutos na memória RAM que não são gravados em disco apenas porque o programador era preguiçoso e não ligou FlushFileBuffers()e depois uma falha de energia. Obviamente, um backup de bateria não protege contra erros de driver que causam um BSOD ....

Em apoio à resposta do ChatBot John Cavil , escrevi um pequeno programa de teste:

// ...
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() `
// ...

E execute-o em um disco Samsung 950pro NVMe com a opção "Desativar a liberação do buffer de cache de gravação do Windows no dispositivo" ativada.

O resultado é:

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()

Assim, você pode ver que a FlushFileBufferssolicitação não é omitida pelo sistema (o Windows não ignora a FlushFileBufferschamada, mesmo que as opções estejam ativadas).