squashfs problema de armazenamento em cache duplo

1

Digamos que há uma imagem grande de squashf em um arquivo. Então, ele é montado como um dispositivo de loopback. Agora, como eu entendo, os kernels de 4.4 e acima eliminaram o cache duplo em dispositivos de loopback. Mas infelizmente, não do squashfs.

Quando você lê algumas coisas dos squashfs montados, a parte compactada da imagem é lida e armazenada em cache pelo Linux. Os dados descomprimidos que você acessa também são armazenados em cache, para que a leitura a partir dele seja muito rápida e não necessite de descompressão novamente.

O segundo cache é muito bom, já que fornece acesso rápido. O primeiro cache é praticamente redundante e completamente inútil. Ele polui o uso da RAM e elimina outras entradas armazenadas em cache (ou força os aplicativos a serem trocados) que são realmente úteis . Este é basicamente o problema do cache duplo.

Contanto que os arquivos já estejam armazenados em cache, descompactados, não faz sentido manter uma versão em cache dos dados compactados .

Se o kernel realmente tiver que abandonar esses caches mais tarde, ele descartará o cache de dados compactados primeiro (usado menos recentemente) e, em seguida, os dados descompactados. Você só vai perceber que quando você ler depois, porque ele terá que reler a partir da unidade e descomprimir novamente. Mas o armazenamento em cache dos dados compactados na unidade é inútil!

Então, para resumir:

  • Mantenha os dados descompactados em cache para que sejam acessados muito rapidamente
  • Não mantenha os dados "comprimidos" do squashfs (no arquivo) em todos os

Eu tentei montá-lo com a opção sync , mas ele não faz nada.

Existe uma solução alternativa que é mais um kludge do que não. Basicamente, o seguinte comando descarta o cache nos dados compactados do squashfs (bom) e não nos dados descompactados (bom):

dd if=root.squashfs iflag=nocache count=0

Eu não toco no ponto de montagem, pois isso derrubaria os dados descomprimidos (o que seria ruim). Em vez disso, eu toco no arquivo subjacente do dispositivo de loop, já que é isso que eu não quero que seja armazenado em cache (como é inútil).

O problema é que o comando deve ser pesquisado repetidas vezes, já que as leituras podem acontecer de qualquer aplicativo a qualquer momento. Então o "kludge" está configurando o comando acima para executar cada segundo ou mais.

É claro que isso é deselegante e um hack completo. Mas pelo menos mostra exatamente o que eu estou procurando. Apenas descarta o cache de arquivos para o arquivo em si (não os arquivos descompactados). Imagine aquele comando rodando a cada milissegundo, é exatamente o que eu quero, mas sem pesquisas como essa. Alguma maneira melhor de fazer isso?

    
por kktsuri 17.05.2018 / 17:41

0 respostas