SSD como um cache de leitura para dados de leitura FREQUENTEMENTE

Question

Estou procurando maneiras de usar um SSD para acelerar meu sistema. Em “ Linux equivalente ao ReadyBoost? ” (e o pesquisa que desencadeou para mim) eu aprendi sobre bcache , dm-cache e EnhanceIO . Todos os três parecem capazes de armazenar dados de leitura no SSD.

No entanto, a menos que eu esteja perdendo algo, todos os três parecem armazenar um arquivo / block / extent / whatever no cache na primeira vez que ele é lido. Leituras sequenciais grandes podem ser uma exceção, mas, do contrário, parece que cada falha no cache de leitura faria com que algo fosse armazenado em cache. Eu gostaria que o cache guardasse as leituras que eu uso frequentemente . Estou preocupado que uma pesquisa sobre os corpos de todos os meus arquivos maildir ou um grep recursivo em algum diretório grande possa despejar grandes porções de coisas que eu leio com muito mais frequência.

Existe alguma tecnologia para armazenar em cache freqüentemente arquivos de leitura, em vez de ler recentemente? Algo que cria alguma forma de conjunto ativo ou algo assim? Eu acho que substituto adaptativo pode ser um termo descrevendo o que eu estou procurando.

Faltando isso, eu me pergunto se faz sentido usar o LVM como uma camada inferior e construir vários dispositivos habilitados para bcache além disso. A ideia é que, por exemplo as leituras de correio não evitam caches para /usr e os gostos. Cada sistema de arquivos montado teria seu próprio cache de tamanho fixo ou nenhum. Alguém tem experiência com bcache em cima de lvm? Existe uma razão contra essa abordagem?

Todas as sugestões alternativas são bem-vindas também. Note, no entanto, que estou procurando algo pronto para uso em produção no Linux. Eu sinto que o ZFS com seu recurso L2ARC não se encaixa nessa categoria (ainda), embora você seja bem-vindo para argumentar esse ponto se estiver convencido do contrário. A razão para o LVM é que eu quero poder redimensionar o espaço alocado para esses vários sistemas de arquivos conforme necessário, o que é um problema usando o particionamento estático. Portanto, as soluções propostas também devem fornecer esse tipo de flexibilidade.

Edit 1: Alguns esclarecimentos.

Minha principal preocupação é o tempo de inicialização. Eu gostaria de ver todos os arquivos que são usados para cada inicialização prontamente acessível naquele SSD. E eu prefiro não ter que se preocupar em manter o SSD em sincronia. após atualizações de pacotes (que ocorrem com bastante frequência nos testes do Gentoo). Se os dados usados com frequência, que eu não uso durante a inicialização, também acabam no cache, isso é um bônus adicional. Meu projeto de trabalho atual, por exemplo seria um bom candidato. Mas eu acho que 90% dos arquivos que eu uso todos os dias serão usados nos primeiros 5 minutos depois de pressionar o botão liga / desliga. Uma conseqüência desse objetivo é que as abordagens que apagam o cache após a inicialização, como o ZFS L2ARC aparentemente faz, não são uma solução viável.

A resposta de goldilocks mudou o foco da inserção do cache para o despejo do cache. Mas isso não muda a natureza fundamental do problema. A menos que o cache rastreie com que frequência ou com frequência um item é usado, as coisas ainda podem sair do cache muito em breve. Particularmente, desde que eu espero que os arquivos que eu uso o tempo todo para residir no cache de RAM do boot até o desligamento, então eles serão lidos do disco apenas uma vez para cada inicialização. As políticas de evicção de cache que encontrei para bcache e dm-cache, ou seja, LRU e FIFO, removeriam esses arquivos de inicialização em vez de outros arquivos lidos no mesmo dia útil. Assim, minha preocupação.

    

Answer 1

No meu melhor entendimento, o dm-cache faz o que você está pedindo. Eu não consegui encontrar uma fonte definitiva para isso, mas aqui o autor explica que ele deveria ter chamado de dm-hotspot, porque ele tenta encontrar "hot spots", ou seja, áreas de alta atividade e apenas armazena essas.

Na saída de dmsetup status , você encontrará duas variáveis, a saber, read_promote_adjustment e write_promote_adjustment . O arquivo cache-policies explica que

Internally the mq policy determines a promotion threshold. If the hit count of a block not in the cache goes above this threshold it gets promoted to the cache.

Então, ajustando read_promote_adjustment e write_promote_adjustment , você pode determinar exatamente o que você quer dizer com frequência dados de leitura / gravação e, quando o número de leituras / gravações exceder esse limite, o bloco será " promovido "para, isto é, armazenado no cache.

Lembre-se de que esses metadados (pré-cache) geralmente são mantidos na memória e gravados apenas em disco / SSD quando o dispositivo de cache é suspenso.

    

Answer 2

However, unless I'm missing something, all three seem to store a file/block/extent/whatever in cache the first time it is read.

A outra opção seria não armazenar nada em cache na primeira vez que for lida e, em vez disso, manter uma contagem do número de vezes que algo é necessário e, em seguida, usar um número arbitrário para decidir quando algo foi "usado com frequência".

Ninguém jamais implementaria um sistema desse modo, porque significa que se dissermos que o número é 10 ou 20 ou 100 vezes, então, quando o número for atingido, é óbvio que o sistema falhou para armazenar em cache um item acessado com frequência o primeiro número X de vezes. Não é tão útil!

I'd like the cache to cache those reads I use often.

Para reiterar o ponto anterior, o que é "frequentemente"? Realisticamente, não poderia ser um número fixo, já que, se o sistema estiver ligado por tempo suficiente, muitas coisas podem se tornar "frequentemente usadas". Pode ser um número escalado para uma "pontuação alta", mas, nesse caso, a escala pode ficar muito desequilibrada se você tiver alguns itens pequenos acessados por um número desproporcional de vezes.

Resumindo: nenhum mecanismo de cache usará uma contagem mínima . Ele vai armazenar em cache tudo até que o cache esteja cheio, então ele vai começar a despejar coisas com base em algum algoritmo de prioridade.

Como "frequência" é um fator "frequente", faz sentido que toda leitura armazene algo em cache, mesmo que seja a primeira vez e o cache esteja cheio, já que o último arquivo lido será "lido com mais frequência". arquivo "se considerarmos uma frequência de" o número de vezes que este arquivo foi lido no passado X lê ", onde X = 1.

I'm worried that a search over the bodies of all my maildir files or a recursive grep in some large directory might evict large portions of stuff I read far more often.

Provavelmente não, se o cache estava cheio para começar. Cada leitura será armazenada em cache, mas também será despejada mais cedo do que as coisas armazenadas em cache que costumam ser acessadas.

I guess adaptive replacement might be a term describing what I'm after.

Observe no "Resumo" nessa página da Wikipédia que a discussão é sobre diferentes estratégias (vs. LRU) para classificar coisas no cache , não coisas que nunca estiveram no cache . Isso segue a lógica que descrevi acima: tudo entra no cache , e a eficácia do mecanismo de armazenamento em cache é determinada pelo algoritmo para remover as coisas do cache . Não colocá-los em.