Como o cache de gravação funciona com um sistema de arquivos que abrange discos com velocidades diferentes?

Em um sistema Linux moderno com vários discos e um RAID de software que abrange unidades lentas (HDD) e rápidas (SSD), como as gravações no sistema de arquivos são armazenadas em cache?

Para MD-ataque RAID1 a matriz pode ser configurado com discos como --write-mostlye --write-behindo que sugere que lê são realizados a partir do disco mais rápido, e que grava o disco mais lenta podem ficar para trás. Mas como isso é armazenado em cache no nível do kernel? O kernel armazena em cache o disco escreve antes ou depois da camada md-raid? No final de uma chamada write () os dados são garantidos para serem gravados em um dos --write-behinddiscos não ?

Para um btrfsRAID1, como seria a mesma situação? Não há --write-behindfuncionalidade; as páginas sujas são contadas no nível do dispositivo ou do sistema de arquivos? Em que ponto um write () retornaria?

Como os vm.dirty_*ratioajustáveis ​​afetam essas configurações?

O --write-mostly, --write-behindé tratado pelo mdmotorista internamente. mdmantém os metadados, como o bitmap de intenção de gravação (que é obrigatório para o recurso de gravação por trás) que basicamente registra quais dados foram gravados ainda e quais ainda estão ausentes. Isso é necessário caso haja um evento de perda de energia, quando os dados ainda não atingiram os dispositivos de gravação. Nesse caso, a área de dados afetada será sincronizada novamente (no seu caso, leia a partir do SSD, grave no HDD).

Mas como isso é armazenado em cache no nível do kernel?

Para o caso write-behind, o driver md basicamente duplica a solicitação de gravação internamente. A solicitação de gravação principal vai para a (s) unidade (s) primária (s) e diz às camadas superiores "OK, eu já fiz isso"; a solicitação de gravação copiada fica em torno do lado de gravação mais atrasada do RAID e pode levar mais tempo para ser concluída, espero que ninguém perceba.

Em seguida, a camada de invasão executa várias etapas para garantir que nenhum dado seja lido do dispositivo de gravação principalmente enquanto ainda houver solicitações de gravação por trás pendentes na fila. Por que os dados seriam lidos a partir de um dispositivo principalmente para gravação? Bem, o SSD pode ter falhado, então é tudo o que resta. É complicado e o write-behind apresenta alguns casos extremos.

Provavelmente é também por isso que ele é suportado apenas no nível RAID-1, e não em nenhum dos outros. Embora possa fazer sentido, em teoria, ter SSDs essencialmente como RAID-0 e dois HDDs com paridade no modo write-behind, não há suporte para um RAID-6 write-behind como esse. É apenas RAID-1 e raramente é usado mesmo lá.

As outras configurações de cache não são afetadas por isso, basicamente o mecanismo geral de cache não se importa nem um pouco com o modo como o mddriver implementou as coisas internamente. O cache faz suas coisas e md faz suas coisas. Portanto, um cache do sistema de arquivos funciona da mesma maneira para um sistema de arquivos em cima do MD versus um sistema de arquivos em cima de uma unidade vazia. (A realidade é um pouco mais complicada do que isso, mas você pode pensar dessa maneira.)

Para MD-ataque RAID1 a matriz pode ser configurado com discos como --write-mostlye --write-behindo que sugere que lê são realizados a partir do disco mais rápido, e que grava o disco mais lenta podem ficar para trás. Mas como isso é armazenado em cache no nível do kernel? O kernel armazena em cache o disco escreve antes ou depois da camada md-raid?

Depois, já que esse recurso é específico para o md-raid.

Você deve considerar esse recurso md-raid como buffer, não como cache. É delimitada pela seguinte mdadmopção:

--write-behind =

Especifique que o modo write-behind deve estar ativado (válido apenas para RAID1). Se um argumento for especificado, ele definirá o número máximo permitido de gravações pendentes. O valor padrão é 256.

Só posso pensar que ele também é limitado pelo buffer normal de kernel e hardware (ou seja, se for menor). O buffer normal do kernel é limitado por nr_requestse max_hw_sectors_kb. Veja /sys/class/block/$write_behind_device/queue/. Por buffer de hardware, quero dizer o cache de gravação na unidade.

No final de uma chamada write () os dados são garantidos para serem gravados em um dos --write-behinddiscos não ?

Obviamente, supondo que você queira dizer que write () esteja em um arquivo aberto com O_SYNC / O_DSYNC, ou você realmente quis dizer write () + fsync (). Caso contrário, nenhuma garantia se aplica.