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

Question

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 são armazenadas no sistema de arquivos?

Para md-raid RAID1, a matriz pode ser configurada com discos como --write-mostly e --write-behind , o que sugere que as leituras sejam executadas a partir do disco mais rápido e que as gravações no disco mais lento possam ficar para trás. Mas como isso é armazenado em cache no nível do kernel? O kernel armazena em cache as gravações do disco antes ou depois da camada md-raid? No final de uma chamada write (), é garantido que os dados sejam gravados em um dos co-de% discos?

Para um --write-behind RAID1, como seria a mesma situação? Não há funcionalidade btrfs , portanto, páginas sujas são contadas em um nível de dispositivo ou em nível de sistema de arquivos? Em que ponto um write () retornaria?

Como os --write-behind ajustáveis afetam essas configurações?

    

Answer 1

O --write-mostly , --write-behind é tratado pelo driver md internamente. md mantém metadados, como o bitmap com intenção de gravação (que é obrigatório para o recurso write-behind) que basicamente registra quais dados foram gravados e em que dados ainda estão faltando. 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 de SSD, escreva para HDD).

But how is that cached at kernel level?

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

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

Qual é provavelmente também porque é suportado apenas para o nível RAID-1, e não para os outros. Embora possa fazer sentido, em teoria, ter SSDs essencialmente como RAID-0 e dois HDDs de 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 armazenamento em cache não se importa nem um pouco sobre como o driver md implementou as coisas internamente. O cache faz a sua coisa e o md faz a sua coisa. Portanto, um cache do sistema de arquivos funciona da mesma maneira para um sistema de arquivos sobre o md, em vez de um sistema de arquivos sobre uma unidade vazia. (A realidade é um pouco mais complicada do que isso, mas você pode pensar assim.)

    

Answer 2

For md-raid RAID1 the array can be configured with disks as --write-mostly and --write-behind which suggests that reads are performed from the faster disk, and that writes to the slower disk can lag behind. But how is that cached at kernel level? Does the kernel cache the disk writes before or after the md-raid layer?

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

Você deve pensar neste recurso md-raid como buffering, não em cache. Ele é limitado pela seguinte opção mdadm :

--write-behind=

Specify that write-behind mode should be enabled (valid for RAID1 only). If an argument is specified, it will set the maximum number of outstanding writes allowed. The default value is 256.

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

At the end of a write() call is the data guaranteed to be written to one of the not---write-behind disks?

Claro, supondo que você queira dizer que o write () estava em um arquivo aberto com O_SYNC / O_DSYNC, ou você realmente quis dizer write () + fsync (). Caso contrário, nenhuma garantia será aplicada.