Segurança do cache de gravação em unidades SATA com barreiras

Question

Eu tenho lido ultimamente sobre cache de gravação, NCQ, bugs de firmware, barreiras, etc sobre unidades SATA, e não tenho certeza qual é a melhor configuração que tornaria meus dados seguros em caso de falha de energia.

Pelo que entendi, o NCQ permite que a unidade reordene as gravações para otimizar o desempenho, mantendo o kernel informado sobre quais solicitações foram gravadas fisicamente.

O cache de gravação faz com que a unidade atenda a uma solicitação muito mais rapidamente, porque não espera que os dados sejam gravados no disco físico.

Não sei como o cache de NCQ e gravação se mistura aqui ...

Sistemas de arquivos, especialmente os de jornal, precisam ter certeza quando uma solicitação específica foi escrita. Além disso, o processo de espaço do usuário usa fsync () para forçar o flush de um arquivo específico. Essa chamada para fsync () não deve retornar até que o sistema de arquivos tenha certeza de que os dados foram gravados no disco.

Há um recurso (FUA, Force Unit Access), que vi apenas em unidades SAS, que força a unidade a ignorar o cache e a gravar diretamente no disco. Para todo o resto, há barreiras de gravação, que é um mecanismo fornecido pelo kernel que pode acionar um cache embutido na unidade. Isso força o all a armazenar o cache, não apenas os dados críticos, diminuindo assim todo o sistema se abusado, com fsync () por exemplo.

Depois, existem drives com bugs de firmware, ou deliberadamente mentem sobre quando os dados foram gravados fisicamente.

Dito isto, existem várias maneiras de configurar as unidades / sistemas de arquivos: A) cache NCQ e Write desativado B) Apenas NCQ habilitado C) Apenas cache de gravação ativado D) Ambos NCQ e cache de gravação ativado

Estou supondo que as barreiras estejam ativadas. BTW, como verificar se elas estão realmente ativadas?

Em caso de perda de energia, enquanto escrevo ativamente no disco, meu palpite é que a opção B (NCQ, sem cache) é segura, tanto para o diário quanto para os dados do sistema de arquivos. Pode haver uma penalidade de desempenho.

A opção D (cache NCQ +), se estiver usando barreiras ou FUA, seria segura para o diário do sistema de arquivos e os aplicativos que usam fsync (). Seria ruim para os dados que estavam aguardando no cache, e cabe ao sistema de arquivos detectá-lo (checksum), e pelo menos o sistema de arquivos não estará (esperançosamente) em um estado instável. Em termos de desempenho, deve ser melhor.

Minha pergunta, no entanto, está ... Estou sentindo falta de alguma coisa? Existe alguma outra variável para levar em conta? Existe alguma ferramenta que possa confirmar isso e que meus discos se comportem como deveriam?

    

Answer 1

Para sistemas corporativos diretos, há uma camada adicional na forma do adaptador de armazenamento (quase sempre uma placa RAID) na qual ainda existe outra camada de cache. Há muita abstração na pilha de armazenamento nos dias de hoje, e eu entrei em detalhes em uma série de blogs que fiz em Conheça sua E / S .

As placas RAID podem ignorar o cache em disco, algumas das quais permitem até mesmo alternar esse recurso no BIOS RAID. Esta é uma razão pela qual os Enterprise disks são Enterprise, o firmware permite tais coisas que as unidades de consumo (unidades especialmente 'verdes') não possuem. Esse recurso aborda diretamente o caso no qual você está preocupado: falha de energia com gravações não-concluídas. O cache da placa RAID, que deve ser bateria ou flashback, será preservado até que a energia retorne e essas gravações possam ser recomortadas.

Certos SSDs corporativos incluem um capacitor integrado com potência suficiente para confirmar o cache onboard antes de ser totalmente desligado.

Se você está trabalhando com um sistema com discos conectados diretamente à placa-mãe, há menos garantias. A menos que os próprios discos tenham a capacidade de confirmar o cache de gravação, uma falha de energia certamente causará uma perda. O sistema de arquivos xfs ganhou reputação por falta de confiabilidade devido à incapacidade de sobreviver apenas a isso Modo de falha; foi projetado para rodar em sistemas corporativos completos com capacidade de sobrevivência de armazenamento projetada.

No entanto, o tempo mudou e o XFS foi projetado para sobreviver a isso. Os outros principais sistemas de arquivos do Linux (bem como ntfs no Windows) já tinha engenharia para sobreviver a este modo de falha. Como isso deve funcionar é que as gravações perdidas não aparecerão no diário da FS e elas saberão que não foram afetadas, então a corrupção será detectada e contornada com segurança.

Você aponta para o único problema aqui: o firmware do disco que está. Neste caso, a revista FS terá feito uma suposição errada versus a realidade e a corrupção pode não ser detectada por algum tempo. O Parity RAID e o mirror RAID podem contornar isso, já que deve haver outra cópia comprometida. Mas as configurações de disco único não terão essa verificação cruzada, por isso, será realmente falha.

Você contorna o risco de firmware usando unidades de nível empresarial que obtêm muito mais validação (e são testadas em comparação com os padrões de carga de trabalho presumidos) e projetam seu sistema de armazenamento para que ele sobreviva a tais inverdades.

    

Answer 2

O diário do sistema de arquivos originalmente aguardava a conclusão da gravação no diário antes de emitir a gravação para os metadados, presumindo que não havia nenhum cache de gravação de unidade. Com o cache de gravação do drive ativado, essa suposição é interrompida e pode causar perda de dados. Assim, barreiras foram criadas. Com barreiras, o diário pode certificar-se de que a gravação no diário seja concluída antes da gravação nos metadados, mesmo que o disco esteja usando o cache de gravação. Na camada do driver de disco, a barreira força o esvaziamento do cache de disco antes que o IO subsequente seja enviado, quando a unidade relata que tem um cache de gravação e está habilitado. Caso contrário, isso não é necessário, portanto, a barreira apenas impede a emissão do IO subsequente para o inversor até que o IO anterior seja concluído. O NCQ apenas significa que ele pode ter que esperar por mais de uma solicitação pendente para concluir antes de emitir mais.