Estou criando um dispositivo dm-cache usando meu script: http://pastebin.com/KTSzL6EA
Efetivamente, ele está executando esses comandos:
dmsetup create suse-cache-metadata --table 0 15872 linear /dev/mapper/suse-cache 0
dmsetup create suse-cache-blocks --table 0 125813248 linear /dev/mapper/suse-cache 15872
dmsetup create storagecached --table 0 2930266112 cache /dev/mapper/suse-cache-metadata /dev/mapper/suse-cache-blocks /dev/mapper/storage 512 1 writethrough default 0
dmsetup resume storagecached
em volume SSD LVM de 60 GB para armazenamento em cache de HDD USB 2.0 de 1,5 TB. Estou montando um dispositivo DM em cache com:
mount -t btrfs -o noatime,autodefrag,compress=lzo,space_cache /dev/mapper/storagecached /mnt/storage
No entanto, parece não funcionar. Percebi que o HDD externo gira TODA vez que estou acessando qualquer conteúdo no dispositivo em cache e toda vez que algum bot está acessando meu site, mesmo que ele deva ser armazenado em cache, eu acho, e é muito chato e finalmente leva a erros de E/S depois cerca de uma semana porque o HDD externo não consegue lidar com aumentos e diminuições contínuas.
Decidi realmente realizar alguns benchmarks e copiar o arquivo de 8 GB para /dev/null com ddo comando atinge apenas 40 MB/s. É a mesma velocidade do HDD sem cache. Sempre. Tanto em simulação com cache limpo, quanto na terceira ou quarta leitura que acho que deveria ser armazenada em cache. O SSD usado para cache atinge 92 MB/s na partição raiz. É claro que depois de cada bancada eu estava limpando o cache RAM do Linux para eliminar o impacto no desempenho do cache RAM.
Na verdade, estou usando esse script em 2 PCs e nenhum deles parece funcionar. Eu sei que a escrita não acelera a escrita, mas estou mais preocupado com a leitura de qualquer maneira.
EDITAR:
Depois de examinar dmsetup statusos logs, percebi que estou obtendo taxas de acertos de cache terrivelmente baixas. Pode ser culpa do Btrfs?
Responder1
O cache dm leva algum tempo para promover blocos no dispositivo de cache. Ao contrário do cache RAM do Linux, a política dmcache padrão requer pelo menos algumas leituras de determinados dados para promovê-los para SSD, geralmente muitas leituras, mais de 10. Combinado com uma quantidade relativamente grande de memória RAM sobressalente na máquina, pode demorar muito de tempo para "treinar" o dmcache. Se o tamanho do cache for semelhante à quantidade de memória RAM sobressalente e os dados usados com frequência ocuparem muito espaço, ele poderá não funcionar decentemente.
Responder2
Use lvmcache(7) para a configuração, você ficará muito mais feliz. Além disso, a página de manual é muito útil para começar a funcionar. Lembre-se das políticas de writeback/writethrough e da política de cache smq, que é padrão apenas nas versões mais recentes (pós-kernel 4.2). Além disso, este é o padrão no RHEL 7.2+ ou algo assim.
Você pode assistir minha palestra:https://www.youtube.com/watch?v=6W_xK5Ks-Lw ou leia os slides:https://www.linuxdays.cz/2017/video/Adam_Kalisz-SSD_cache_testing.pdf