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

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

Pelo que entendi, o NCQ permite que a unidade reorganize 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 NCQ e o cache de gravação se misturam aqui ...

Os sistemas de arquivos, especialmente os de diário, precisam ter certeza de quando uma solicitação específica foi anotada. Além disso, o processo de espaço do usuário usa fsync () para forçar a liberação 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 estão gravados no disco.

Há um recurso (FUA, Force Unit Access), que eu vi apenas nas unidades SAS, que força a unidade a ignorar o cache e gravar diretamente no disco. Para todo o resto, existem barreiras de gravação, que é um mecanismo fornecido pelo kernel que pode disparar um fluxo de cache na unidade. Isso força todo o cache a ser gravado, não apenas os dados críticos, retardando o sistema inteiro se for abusado, com fsync () por exemplo.

Depois, existem unidades com bugs de firmware ou que deliberadamente ficam sobre quando os dados foram gravados fisicamente.

Dito isto .. existem várias maneiras de configurar as unidades / sistemas de arquivos: A) NCQ e cache de gravação desativados B) Apenas NCQ ativado C) Apenas cache de gravação ativado D) O NCQ e o cache de gravação ativados

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

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

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

Minha pergunta, no entanto, permanece ... Estou perdendo alguma coisa? Existe alguma outra variável a ser levada em consideração? Existe alguma ferramenta que possa confirmar isso e que minhas unidades se comportem como deveriam?

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. Existe uma grande quantidade de abstração no armazenamento empilhar estes dias, e eu entrei em profunda detalhe neste em uma série de blog que eu fiz em conhecer o seu I / O .

As placas RAID podem ignorar o cache do disco, algumas das quais permitem alternar esse recurso no BIOS RAID. Essa é uma das razões pelas quais os discos Enterprise são Enterprise; seu firmware permite coisas que as unidades de consumo ( especialmente as unidades 'verdes') não permitem . Esse recurso aborda diretamente o caso em que você está preocupado: falta de energia com gravações não confirmadas. O cache da placa RAID, que deve ser com bateria ou com flash, será preservado até que a energia retorne e essas gravações possam ser recompetadas.

Certos SSDs corporativos incluem um capacitor integrado com capacidade suficiente para confirmar o cache integrado antes de desligar totalmente.

Se você estiver 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, um defeito de energia causará realmente uma perda. O sistema de arquivos xfs ganhou uma reputação de não ser confiável devido à sua incapacidade de sobreviver apenas a este modo de falha; foi projetado para rodar em sistemas corporativos completos com capacidade de sobrevivência de armazenamento de engenharia.

No entanto, o tempo passou e o XFS foi projetado para sobreviver a isso. Os outros principais sistemas de arquivos Linux (assim como o NTFS no Windows) já tinham engenharia para sobreviver a esse mesmo modo de falha. Como ele deve funcionar é que as gravações perdidas não aparecerão no diário FS e saberão que não foram confirmadas, portanto a corrupção será detectada e contornada com segurança.

Você aponta para o único problema aqui: o firmware do disco que está. Nesse caso, o diário FS terá feito uma suposição errada em relação à realidade e a corrupção poderá não ser detectada por algum tempo. O RAID de paridade e o RAID de espelho podem solucionar esse problema, pois deve haver outra cópia confirmada para retirada. Porém, as configurações de disco único não terão essa verificação cruzada, portanto, ocorrerão falhas.

Você evita o risco de firmware usando unidades de nível corporativo que obtêm muito mais validação (e são testadas em relação aos padrões de carga de trabalho presumidos) e projetando seu sistema de armazenamento para que ele possa sobreviver a tais inverdades.

O diário do sistema de arquivos originalmente aguardou a gravação no diário antes de emitir a gravação nos metadados, assumindo que não havia cache de gravação na unidade. Com o cache de gravação da unidade ativado, essa suposição é quebrada e pode causar perda de dados. Assim, barreiras foram criadas. Com barreiras, o diário pode garantir que a gravação no diário seja concluída antes da gravação nos metadados, mesmo se o disco estiver usando o cache de gravação. Na camada do driver de disco, a barreira força a liberação de um cache de disco antes do envio das E / S subsequentes, quando a unidade informa que possui um cache de gravação e está ativada. Caso contrário, isso não é necessário; portanto, a barreira impede a emissão do IO subsequente no inversor até que o IO anterior seja concluído. O NCQ significa apenas que talvez seja necessário aguardar a conclusão de mais de uma solicitação pendente antes de emitir mais.