Qual é a função e o efeito total de “Desativar a limpeza do buffer do cache de gravação do Windows no dispositivo”

Question

No Windows 7, usando o Gerenciador de dispositivos, exibindo as propriedades de um disco e indo para a guia Políticas, há dois itens de alternância. O cache de gravação, que esta questão não se trata.

e

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

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

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

1. Alterando ações de gravação para programas paranóicos: (fato ou ficção)
 Ele altera a maneira como os fluxos de gravação funcionam em um programa que força a liberação do cache? Alguns programas estão muito empenhados em terminar a escrita, sem especular, esses programas são capazes de continuar com sua escrita de proteção, ou isso muda também para esses programas?

2. Tipos de programas efetuados:
Quais são os tipos de ações / programas que seriam ou não afetados pela mudança? Digite, alguns programas fluem, alguns escrevem rapidamente, alguns 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 uma referência mesmo:
Se a configuração estiver ativada, quais são as mudanças observáveis por escrito? Qualquer exemplo solto de uma mudança observada no comportamento. ou observou nenhuma mudança no comportamento?

4. Qual é o atraso ou atraso:
Sabemos que a maioria dessas ações é muito rápida na maioria dos computadores. Os dados, eventualmente, 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 questões, se você gostaria de cobri-lo, isso não atrapalharia.

O que significa "Escrever cache de limpeza do buffer" significa é quase um truque disso, mas o link é para um sistema operacional diferente. Embora o A tenha alguma informação, mesmo o termo usado no link não é o mesmo. Ele também não responde às coisas mais significativas que um usuário gostaria de saber, que tentei descrever aqui.

    

Answer 1

1. Sua afirmação na primeira questão é ficção. Chamadas de API do Windows, como, por exemplo, FlushFileBuffers() will FileStream.Flush() no .NET, etc., eventualmente, chamam essa API.

2. Programas que fazem muita E / S de disco sem chamar FlushFileBuffers() diretamente, ou qualquer API auxiliar que eventualmente a chama, veriam o aumento de desempenho mais notável. Por exemplo, se você estava executando uma E / S não essencial, em que os dados se perdem, como o BOINC (se for perdido, basta baixar novamente o arquivo ou tentar recalcular os cálculos), evite fazer chamadas FlushFileBuffers() , e apenas chame uma API como WriteFile() - os dados serão bufferizados para serem gravados, mas não serão gravados por um longo período, como quando o arquivo o descritor é fechado ou quando o programa sai. Infelizmente também é possível que, se o sistema travar (como um BSOD), todos os dados sejam perdidos, então é realmente importante que se você estiver lidando com qualquer tipo de dados valiosos / não substituíveis. que você faz fazer chamar FlushFileBuffers() , se a limpeza do buffer está ativada ou não! Caso contrário, um simples bug de driver (por exemplo, no seu driver gráfico) pode causar a perda de muitos dados.

3. Não é possível encontrar nenhuma referência, mas você notará mais com programas que se encaixam na descrição do segundo item acima.

4. A sincronização de dados para o disco não é tão rápida assim, especialmente se for feita com frequência em um loop estreito. Por padrão, se bem me lembro de ler livros do Windows Internals, o NTFS por padrão sincroniza todos os buffers de sistema de arquivos sujos com o disco a cada 5 segundos . Esta é aparentemente uma compensação decente entre estabilidade e desempenho. O problema com a sincronização freqüente de dados é que faz com que o disco rígido faça muitas buscas e escritas.

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 o buffer automático de 5 segundos em :

• As gravações ocorridas nas linhas 2, 5 e 7 ocorrem na RAM e o disco não se move, até que 5 segundos se passaram desde a primeira gravação e, em seguida, os dados mais recentes (da linha 7 ) é gravado no bloco (1) e os únicos dados gravados no bloco (2) são gravados.
• As gravações ocorridas nas linhas 10 e 13, que sobrescrevem dados nos blocos (1) e (2), precisam ser gravadas no disco novamente
• Assim, 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 escrito para RAM é 2 e para disco , 2.

Com o buffer automático de 5 segundos desativado (o efeito da caixa de seleção na sua pergunta):

• As gravações ocorridas nas linhas 2, 5, 7, 10 e 13 ocorrem na RAM e o disco não se move, até que a linha 14 seja executada e, em seguida, os dados mais recentes (das linhas 10 e 13) é escrito em 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 a dezenas de milhares de gravações em arquivos por segundo, isso é ótimo para desempenho, especialmente em discos rígidos tradicionais (é menos impressionante em SSDs). A RAM é 20 vezes mais rápida do que os discos rígidos como medida geral, embora essa lacuna seja menor com os SSDs.

A razão pela qual eles dizem que você deve usar um backup de bateria é que você não quer ter 35 minutos de dados escritos armazenados em buffer na memória RAM que não são gravados no disco apenas porque o programador era preguiçoso e não ligou para%.FlushFileBuffers() e, em seguida, ter uma falha de energia. Claro, um backup de bateria não protege você contra erros de driver que causam um BSOD ....

    

Answer 2

Em apoio a resposta do ChatBot John Cavil , Eu escrevi um pequeno programa de testes:

// ...
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 o esvaziamento do 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 solicitação FlushFileBuffers não é omitida pelo sistema (o Windows não ignora FlushFileBuffers da chamada mesmo se as opções estiverem ativadas).