Para o RaspPhotoPipe ser útil, pelo menos deveria ser possível copiar um imagem em raw abaixo de 1 segundo. Com os meus último resultado, conseguia copiar em ficheiro raw (cerca de 20Mb na minha máquina) em cerca de 2 segundos. Não é muito mau, mas deveria ser melhor. Por isso fui à procura de formas de melhorar o raspberry pi.

Algo que aprendi com isto, é que, nem sempre o maior é o melhor, isto porque sendo um equipamento com poucos recursos, é fácil de os esgotar.

Primeiro, vou tentar obter o melhor dos discos USB, com o mínimo de recursos.

De acordo com esta pergunta é possível configurar um parâmetro no kernel que se pode obter mais do USB. Este parâmetro é o max_sectors, que limita o número de bytes pedidos em cada comando.

Na minha configuração, o parametro max_sectors será de 192, porque mesmo pedindo mais informação, não obtenho maior débito.

O próximo passo é melhorar como o kernel lida com as chamadas de I/O.

O kernel do Linux, implementa 4 diferentes algoritmos para lidar com os dados de um disponsitivo, e este são conhecidos como schedulers. Podem encontrar no StackOverFlow uma pequena explicação.

No Raspbian, só existem 3 no kernel: noop, deadline e cfq.

Não se deixem enganar pelo gráfico, porque se eu não tivesse alterado a escala, quase não se notava a diferença entre eles, por isso, não penso que alterar o scheduler irá fazer diferença no fim.

Depois de correr o script os melhores valores que obtenho são:

Chunk size de 32 bytes e a stripe cache size para 4096 bytes. A chunk size de 8bytes poderia ter melhoria na escrita, mas tornaria a velocidade de leitura muito pior.

Para terminar, ver qual o melhor sistema de ficheiros.

Até agora, todos os testes foram fazendo um DD de /dev/zero para o disco. Mas com este teste, tenho dois problemas: Primeiro não imita a forma como vão ser copiados os dados e por outro lado é muito consumir de recursos do raspberry pi. Se estiver ocupado a gerar zeros para escrever no disco, não pode ao mesmo tempo estar a fazer o processamento necessário para escrever os dados no RAID.

Por isso alterei a maneira de fazer os testes. Por isso a minha metodologia passou a ser copiar ficheiro a ficheiro da memória do raspberry pi para o disco em RAID. E também deixei de fazer testes com o stripe cache abaixo de 1024 bytes.

Uma grande alteração nos valores, correto? Pois, mas estes dados são de alguma forma enganadores, porque a origem dos dados é memória, e o destino, devido à cache do RAID também é memória. Deste gráfico a única coisa que concluo é que o XFS será a minha primeira escolha como sistema de ficheiros, porque está a ser o mais consistente nos testes, mesmo tendo um pior desempenho que o BTRFS-

Já agora, lembra-se de eu no último post, ter colocado a hipótese de compilar os módulos estaticamente no kernel para isto ser mais rápido... bom aqui têm a vossa resposta... não existem alterações significativas, por isso, não vale a pena perder tempo a recompilar o kernel só por causa disto.

A minha última tentativa de fazer testes semelhantes ao cenário final, é copiar os ficheiro do cartão de memória para o RAID. Não existem diferenças entre os sistemas de ficheiros.

Depois de tantas horas de testes para chegar a uma conclusão: Provavelmente o estrangulamento será no USB e não no desempenho do RAID.