Estou escrevendo um destino de mapeador de dispositivos e estou tendo um problema. Ao executar um teste de E / S, o número de i / o em andamento para o meu destino fica muito alto, presumivelmente no sistema de arquivos que faz o paging do cache. Às vezes, vejo dezenas de milhares de i / o em voo para o meu alvo, o que faz com que ele não responda a outros comandos nele. Existe uma maneira de limitar a quantidade de E / S enviada de uma vez? Os alvos baseados em solicitações têm um retorno de chamada ocupado, o que parece ser o suficiente, mas há limites para o tipo de dispositivos que podem ser mapeados, o que é um problema para mim. A maioria dos alvos bio-base existentes configuram uma função congestionada, mas isso não parece resolver o problema. Retornar DM_MAPIO_REQUEUE ou concluir a E / S com EBUSY acaba de ser convertido em EIO na maioria dos cenários e causar falhas nas operações.
Depois de brincar com os destinos existentes, bem como com alguns códigos de teste, parece que a alta entrada e / ou está associada a alvos que colocam E / S em uma fila de trabalho para processamento, enquanto envia imediatamente a E / S para o processamento. dispositivo de apoio limita isso. Se isso for verdade, não consigo encontrar o mecanismo pelo qual a limitação ocorre.
Existe uma maneira de retardar o fluxo de entrada e saída? Ou, em caso negativo, existem práticas recomendadas para manter o dispositivo responsivo? Ou uma recomendação para a ordem em que eles devem ser tratados?
Tags linux device-mapper