Eu estava testando bache no raspberry pi 4 com o Ubuntu. A razão pela qual escolhi o ubuntu é que encontrei o raspbian padrão com alguns problemas com o bcache, pois o módulo do kernel não foi carregado corretamente. Eu tentei solucionar um pouco, mas depois mudo para o Ubuntu e funciona imediatamente
Minha configuração é assim.
1 x 1TB HGST 5400RPM 2.5 laptop hard disk
1 x 256GB WD Green 2.5 SSD
Raspberry pi 4 4GB model with large heat-sink for cooling and 4A power.
Conectei o HDD e o SSD ao raspberry pi (ambos alimentados externamente) usando portas USB 3.0 e inicializei no Ubuntu. Primeiro testei os erros de subtensão e achei tudo normal.
SSD -> /dev/sda
HDD -> /dev/sdb
Então eu crio 1 partição em ambas as unidades e crio o bcache da seguinte forma.
make-bcache -B /dev/sdb1
make-bcache -C /dev/sda1
então eu monto o /dev/bcache0 em /datastore
então eu anexei o dispositivo de cache da seguinte forma
echo MYUUID > /sys/block/bcache0/bcache/attach
Então eu habilitei o cache de write-back
echo writeback > /sys/block/bcache0/bcache/cache_mode
Então eu instalei o servidor vsftpd e fiz o root ftp dir como meu ponto de montagem bcache0 e comecei a testar. Nos primeiros testes, posso fazer upload de arquivos de 113 MBps e percebo que a maioria dos arquivos grava diretamente no dispositivo de apoio, mesmo que o cache esteja anexado.
quando testei o status usando o script bcache-status https://gist.github.com/damoxc/6267899 vi que a maioria das gravações perde o cache e grava diretamente no dispositivo de backup e os 113 MBps são diretamente do disco rígido mecânico :-O ?
Então eu comecei a afinar. Conforme sugerido na parte de solução de problemas de desempenho deste documento https://www.kernel.org/doc/Documentation/bcache.txt
primeiro eu defino sequencial_cutoff para zero executando este comando
echo 0 > /sys/block/bcache0/bcache/sequential_cutoff
Depois disso, posso ver instantaneamente que os acessos ao cache do dispositivo SSD são aumentados. E ao mesmo tempo eu estava executando o iostat continuamente. E pude ver que o SSD iostat está sendo acessado diretamente. Mas depois de alguns minutos meu cliente filezilla trava e não consigo reiniciar o fluxo de upload do FTP. E quando tento acessar a montagem bcache0 fica muito lento. o status do cache estava mostrando como "sujo"
Então reinicio o pi e novamente conectei o dispositivo. e defina abaixo steting
echo 0 > /sys/fs/bcache/MYUUID/congested_read_threshold_us
echo 0 > /sys/fs/bcache/MYUUID/congested_write_threshold_us
De acordo com o artigo https://www.kernel.org/doc/Documentation/bcache.txt , isso é para evitar a latência do dispositivo de backup da trilha bcache. Mas mesmo depois desta opção. meu fluxo de upload FTP travando continuamente. Então eu configurei tudo de volta para o padrão. Ainda com grande número de uploads de arquivos, ele trava
E notei que dentro do teste pi a CPU não é totalmente utilizada.
A taxa de transferência máxima que posso obter usando pi 4 Ethernet de 1 Gbps é de 930 Mbps, o que é extremamente bom. O drive HGST quando testei com cristal marca disco com NTFS capaz de gravar até 90MBps. Parece que posso obter 113 MBps no pi, pois o sistema de arquivos é ext4.
Se eu conseguir mais de 80 MBps de velocidade de upload de ftp, estou bem com isso. Minhas perguntas são
Por que o fluxo de FTP continua travando ao usar com bcache e por que a montagem do bcache fica lenta ao longo do tempo.
por que há um uso de cache muito baixo, mesmo com o sequencial_cutoff definido como 0
Alguém já testou bcache antes com Raspberry PI 4? se sim, como posso usar o SSD para armazenar em cache corretamente
E, finalmente, alguém pode explicar mais sobre como o bcache realmente funciona quando está no modo writeback. Eu só uso isso para dados de arquivamento e não preciso acessar dados quentes no tipo de configuração SSD.
