ATUALIZAÇÃO: Tentei este cenário em uma placa com oito portas SATA extras e funcionou. Mais lento do que eu pensava, mas ainda aceitável. De acordo com a discussão com David Schwartz, acredito que ele pode estar correto ao dizer que há algo patologicamente errado ou que Ali Chen pode estar certo ao dizer que o RHEL simplesmente não consegue lidar com tantos controladores de host funcionando ao mesmo tempo. Vou experimentar um pouco mais, já que cheguei até aqui e basicamente estou sendo pago para ser curioso neste momento. :)
COMECE A POSTAGEM ORIGINAL
Portanto, a configuração é um pouco demorada. Temos duas placas RocketU 1144D de 4 portas USB 3.0 em nosso sistema, uma em um soquete PCIe 2.0 e outra em um soquete PCIe 3.0 para evitar problemas de largura de banda. Cada uma dessas placas USB possui quatro SSD Crucial MX300 de 1 TB em gabinetes Silver Stone Raven com alimentação externa conectados a ela. A necessidade, por parte do cliente, é poder gravar simultaneamente o mesmo conjunto de arquivos em quatro dos oito discos enquanto lê arquivos dos outros quatro discos para calcular somas de verificação MD5. Cada disco estará o mais próximo possível da capacidade com arquivos com aproximadamente 1 GB de tamanho no momento da leitura ou após a gravação de todos os arquivos.
Agora, se apenas acessarmos ou gravarmos arquivos em discos de um dos cartões as velocidades não serão tão ruins. Com TB completo, temos uma média de 3 a 4 segundos por arquivo (leitura/calculo ou gravação). O problema é que quando tentamos fazer as duas coisas ao mesmo tempo, as velocidades de leitura e gravação diminuem rapidamente, passando de aproximadamente 1,5 segundos por arquivo para mais de sessenta segundos por arquivo.
As únicas outras placas no sistema são a placa de vídeo no slot PCIe 3 16x e um adaptador Intel X540-T2 (não usado atualmente) em outro dos slots PCIe 3 8x.
Temos um servidor MOBO de CPU dupla X10DRL-i com dois processadores Zenon de 6 núcleos e 64 GB de RAM executando RHEL 7.2 de outro Crucial MX300 conectado a uma porta SATA.
Então, a questão é: é possível fazer o que está descrito acima dentro de um período de tempo razoável definido como: mil arquivos de um gigabyte por SSD lidos de quatro SSDs conectados ao cartão um gravado em quatro SSDs conectados ao cartão dois as operações DEVEM ser feito em paralelo (por causa do cliente) tudo em menos de uma hora?
Pelo que estou aprendendo, estou começando a me inclinar para não, mas pensei em perguntar e ver se alguém com mais conhecimento do que eu tem algo mais definitivo. Qualquer ajuda, conselho e especialmente uma resposta são muito apreciadas.
EDIT por sugestão de David Schwartz:
Largura de banda necessária por placa 5 Gbps por porta USB 3.0 x4 portas = 20 Gbps
Largura de banda disponível PCIe 2.0 x4 a 500 MBps por pista = 16 Gbps
Como uma placa está usando as pistas PCIe 3 e a outra as pistas PCIe 2, não deve haver conflito para esses recursos, pelo que entendi.
OBSERVAÇÃO:
Eu sei que o cartão foi vendido em largura de banda, mas as leituras e gravações não devem durar vários minutos por arquivo GB.
EDITAR 2:
Após a sugestão de David Schwartz, monitorei o uso principal usando o monitor do sistema e o htop. O sistema mostra 100% ou quase 100% de uso ou quatro núcleos para a primeira dúzia de IOs de arquivo. O sistema irá então congelar por alguns segundos e é quando ocorre a degradação de E/S do arquivo. Além disso, a utilização do núcleo raramente chegará a 100% depois disso e, quando isso acontece, é muito brevemente.
EDIT 3: Provavelmente a edição final.
Depois de um pouco de pesquisa e experimentação, acho que podemos dizer que isso não vai funcionar para a placa em questão e aposto que a placa StarTech mencionada nos comentários também não funcionará. Acredito que podemos chegar a essa conclusão com base em várias coisas. Resumindo, um SSD funciona muito bem na placa. Dois funcionam bem com um pouco de lentidão; sobrecarga, eu acho. No entanto, 3 ou mais começam a fazer coisas ruins. Imagino que isso seja porque estamos tentando aumentar 20 Gbps em pistas PCIe de 16 Gbps e, em vez de obter o máximo teórico de 16 Gbps, os controladores em ambos os lados da transmissão podem estar tropeçando uns nos outros e geralmente fazendo com que as coisas voltem ao ponto de retardando a transferência de dados para um rastreamento. Esta é apenas uma teoria, mas foi boa o suficiente para fazer com que o cliente abandonasse o requisito USB e nos permitisse experimentar o SATA e outros métodos. A SATA está funcionando muito, MUITO melhor, então acho que temos um vencedor. Obrigado a David Schwartz e Ali Chen pela ajuda e sugestões.
EDIT 4: A edição final real
Então, ontem me deparei com a resposta à minha pergunta em várias partes enquanto analisava as soluções SATA. O problema real era duplo e só se tornou aparente depois que o primeiro dos problemas foi descoberto.
Então, o primeiro problema foi o gerenciamento de memória. Depois de testar o software que lê os arquivos grandes para gravação, parecia que os arquivos estavam sendo lidos uma vez e depois gravados várias vezes. Este não era o caso. Portanto, tivemos várias solicitações de leitura para vários arquivos de 1 GB acontecendo constantemente. Não tenho certeza por que isso funcionou nos testes, mas não na prática, mas não tivemos tempo de fazer uma autópsia, então isso fica para a história.
O segundo problema é que não somos caras de hardware e por isso não sabíamos de um detalhe muito importante enquanto trabalhávamos em um sistema Linux. Como o NTFS não é nativo do Linux (isso nós sabíamos), aparentemente ele rodará quase uma ordem de magnitude mais lenta (isso nós não sabíamos). Se esta fosse uma caixa do Windows, não teríamos problemas.
Combine esses dois fatores e você obterá o comportamento errático que experimentamos. Depois que fizemos uma reformatação completa de todos os discos para EXT4, paramos de ver os tempos imprevisíveis de leitura/gravação e tudo funcionou conforme o esperado. Poderíamos fazer gravações simultâneas e cálculos de leitura/md5 dentro dos parâmetros permitidos.