IBM Storage Ceph Acelera o Desempenho do Cluster, mas o Teste de Benchmark Vem a Seguir

O IBM Storage Ceph acelera o desempenho do cluster na versão 9.9.2 ao mover metadados frequentemente acedidos para armazenamento mais rápido, em vez de os deixar em dispositivos mais lentos.

A versão de 14 de outubro introduz o BlueFS Spillover Cleaner, um mecanismo automatizado de escalonamento por níveis para metadados geridos através do RocksDB. A IBM afirma que o recurso deve melhorar a consistência e reduzir a latência para cargas de trabalho importantes. No entanto, o seu anúncio não apresenta resultados de benchmark.

Essa lacuna cria a tensão central. A IBM resolveu um problema real de desempenho em clusters Ceph com suportes mistos, mas os compradores ainda precisam de evidências ao nível das cargas de trabalho. A versão desafia a premissa de que melhorar um cluster de armazenamento distribuído exige sempre mais flash, mais nós ou uma grande renovação de hardware.

Também pressiona as implementações do Ceph pela comunidade e as plataformas de armazenamento concorrentes. Os administradores devem agora avaliar se o posicionamento automatizado de metadados proporciona ganhos significativos sem acrescentar riscos inaceitáveis de migração, monitorização ou atualização.

IBM Storage Ceph Acelera o Desempenho do Cluster Através do Escalonamento de Metadados

A alteração importante não é um novo protocolo de armazenamento. É uma decisão automatizada sobre onde o Ceph mantém os seus metadados mais ativos.

O IBM Storage Ceph 9.9.2 tornou-se geralmente disponível em 14 de outubro de 2026. A IBM descreve o produto como uma plataforma definida por software com suporte empresarial, que fornece armazenamento em bloco, ficheiros e objetos através de uma única pilha tecnológica.

O recurso de desempenho no centro da versão é o BlueFS Spillover Cleaner. A IBM também chama ao seu mecanismo subjacente um gestor inteligente de escalonamento por níveis do BlueFS.

O BlueFS é um pequeno sistema de ficheiros utilizado pelo BlueStore, o backend de armazenamento do Ceph, para gerir ficheiros do RocksDB. O RocksDB é uma base de dados integrada de chave-valor que regista metadados internos, incluindo mapeamentos entre objetos lógicos e armazenamento físico.

Um dispositivo de armazenamento Ceph pode utilizar vários níveis de suporte. O dispositivo WAL contém o registo write-ahead, enquanto um dispositivo DB opcional armazena metadados do RocksDB. O dispositivo principal contém dados de objetos e também pode receber metadados que já não cabem noutro local.

Os administradores habitualmente colocam as funções DB e WAL em SSDs ou dispositivos NVMe. Podem então manter grandes conjuntos de dados de objetos em discos rígidos menos dispendiosos.

Essa arquitetura cria um importante modo de falha. Quando o dispositivo DB rápido fica cheio, os ficheiros do RocksDB podem transbordar para o dispositivo de dados principal. Um disco rígido pode fornecer capacidade adequada, mas o acesso aos metadados torna-se mais lento e menos previsível após esse transbordamento.

O novo gestor analisa continuamente os padrões de acesso aos ficheiros. De acordo com o resumo da versão 9.9.2 da IBM, ele relocaliza ficheiros frequentemente acedidos para o dispositivo DB e move ficheiros menos ativos para suportes mais lentos.

O mecanismo assemelha-se à gestão de cache, mas opera sobre ficheiros do RocksDB em vez de objetos das aplicações. Procura reservar a capacidade limitada de alta velocidade para os metadados que contribuem mais diretamente para as cargas de trabalho ativas.

Essa distinção é importante. As aplicações não precisam de identificar metadados ativos nem emitir comandos especiais de posicionamento. A camada de armazenamento monitoriza a atividade e altera o posicionamento dos ficheiros nos bastidores.

A análise inicial de desempenho argumenta que este arranjo mantém metadados de elevado valor em suportes mais rápidos. Também deve impedir que ficheiros de bases de dados inativos consumam indefinidamente a escassa capacidade dos SSDs.

A IBM afirma que o resultado é um acesso aos metadados mais eficiente, menor latência e desempenho mais consistente do cluster. Essas declarações continuam a ser alegações do fornecedor até que testes independentes meçam o efeito sob cargas de trabalho reproduzíveis.

O IBM Storage Ceph 9.9.2 também inclui atualizações mais amplas. Estas abrangem a gestão de gateways NVMe/TCP, navegação de objetos S3, quarentena CephFS, failover NFS, integração SMB e administração de clusters.

Várias adições continuam a ser pré-visualizações tecnológicas. A deduplicação completa de objetos, a migração transparente de estado NFS, o suporte SMB para macOS e o acesso SMB através de S3 não são todos posicionados como recursos maduros para produção.

O BlueFS Spillover Cleaner é diferente porque aborda o núcleo RADOS, a camada de objetos distribuídos sob os serviços Ceph. Os seus efeitos podem, portanto, alcançar cargas de trabalho expostas através de múltiplas interfaces.

O recurso também visa um problema operacional recorrente, em vez de adicionar outro método de acesso. A IBM procura extrair um desempenho mais estável do hardware que muitos clientes já utilizam.

Isso torna esta atualização mais relevante do que a sua descrição limitada sugere. Os compradores de armazenamento recebem um mecanismo de software que pode adiar a expansão de hardware, desde que a melhoria se mantenha em condições reais de implementação.

Porque o Posicionamento de Metadados se Torna uma Questão de Desempenho em Todo o Cluster

Uma pequena quantidade de metadados mal posicionados pode influenciar um conjunto de dados muito maior, porque cada operação sobre objetos depende de mapeamentos internos precisos.

O Ceph distribui informação por muitos daemons de armazenamento de objetos, conhecidos como OSDs. Cada OSD gere um dispositivo de armazenamento local e participa em replicação, recuperação, reequilíbrio e operações de clientes.

O BlueStore escreve dados diretamente em dispositivos de bloco brutos. Utiliza o RocksDB para metadados que descrevem onde residem os objetos e os seus componentes. O BlueFS fornece serviços de sistema de ficheiros a essa base de dados.

Uma consulta de metadados é pequena em comparação com uma grande transferência de objetos. Ainda assim, consultas atrasadas podem estar no caminho crítico de muitos pedidos de aplicações. O efeito torna-se mais visível quando as cargas de trabalho geram grandes quantidades de operações pequenas ou aleatórias.

O desempenho também pode tornar-se inconsistente, em vez de uniformemente lento. Um pedido pode alcançar metadados num SSD, enquanto outro acede a um ficheiro RocksDB que transbordou para um disco rígido.

O débito médio pode ocultar essa diferença. Plataformas de bases de dados, máquinas virtuais e análises interativas respondem frequentemente de forma mais visível à latência de cauda longa do que à largura de banda sequencial anunciada.

É por isso que a decisão da IBM de automatizar o posicionamento é importante. Um cluster pode ter dispositivos DB rápidos instalados, mas utilizá-los mal após a alteração da sua ocupação de metadados.

O crescimento pode produzir essa condição gradualmente. Mais objetos, snapshots, buckets ou grupos de posicionamento aumentam a pressão sobre os metadados, mesmo que o hardware subjacente permaneça saudável.

Os eventos operacionais podem acrescentar mais pressão. Reequilíbrio, recuperação, compactação e atividades de manutenção podem alterar padrões de acesso ou competir por recursos dos dispositivos.

Os administradores podem dimensionar dispositivos DB e monitorizar o transbordamento, mas planos estáticos nem sempre correspondem a cargas de trabalho em evolução. Um cluster concebido para objetos grandes pode posteriormente receber muitos ficheiros menores ou imagens de máquinas virtuais que mudam rapidamente.

O BlueFS Spillover Cleaner tenta tornar o nível rápido adaptativo. Promove ficheiros RocksDB ativos e rebaixa os mais frios de acordo com o acesso observado.

O conceito é fácil de compreender, mas a sua implementação levanta questões difíceis. O gestor tem de identificar padrões úteis sem criar I/O excessivo em segundo plano. Também deve evitar mover ficheiros com tanta frequência que o escalonamento por níveis consuma o benefício que procura alcançar.

A IBM não publicou os limites da política nem um modelo detalhado de decisão no seu anúncio. Por isso, os compradores não têm uma visão clara da rapidez com que o gestor reage a mudanças nas cargas de trabalho.

Também precisam de saber como o recurso se comporta durante a compactação. O RocksDB reorganiza periodicamente ficheiros de dados, criando atividade de escrita que pode alterar tamanhos de ficheiros e padrões de acesso.

O cleaner poderá ser particularmente valioso em clusters híbridos que combinam discos rígidos de elevada capacidade com dispositivos SSD menores para metadados. Esses sistemas apresentam a maior diferença de desempenho entre suportes DB e SLOW.

Os clusters totalmente flash apresentam um caso diferente. Mover metadados entre dois níveis de flash ainda pode ser importante, mas a diferença de latência pode ser menor. CPU, rede ou serialização de software podem tornar-se a principal limitação.

As orientações de hardware da IBM enfatizam que o Storage Ceph pode funcionar em sistemas comuns não proprietários. Suporta processadores Intel e AMD x86-64, enquanto a versão 9.9.0 adicionou suporte completo a ARM.

Essa flexibilidade de hardware é central para o apelo do Ceph. Também significa que nenhuma alegação única de desempenho pode representar todas as implementações.

O tipo de unidade, o desenho da rede, a densidade de OSDs, a alocação de CPU, o domínio de falha, a política de proteção de dados e o tamanho dos objetos podem todos alterar os resultados. Um recurso de escalonamento por níveis herda essa variabilidade.

A promessa prática é, portanto, mais limitada do que simplesmente tornar o Ceph mais rápido. O IBM Storage Ceph acelera o desempenho do cluster quando o transbordamento de metadados é um gargalo relevante e ainda existe capacidade DB mais rápida disponível.

Essa condição existirá em muitos sistemas de suportes mistos, mas não em todos. Os compradores devem primeiro identificar a origem da sua latência antes de tratar uma atualização como uma solução universal.

A Verdadeira Disputa é Entre Otimização de Software e Expansão de Hardware

O argumento mais forte da IBM é que um posicionamento mais inteligente pode recuperar desempenho sem obrigar os clientes a substituir o nível de capacidade do cluster.

Uma resposta comum à pressão sobre o armazenamento é adicionar recursos. Os administradores podem instalar dispositivos DB maiores, substituir discos rígidos por SSDs, adicionar nós ou redesenhar a rede.

Essas ações podem funcionar, mas afetam orçamentos, calendários de manutenção, planeamento de falhas e capacidade física. A expansão de um cluster distribuído também pode desencadear movimentação de dados antes de os novos recursos proporcionarem todo o seu benefício.

O BlueFS Spillover Cleaner oferece outra via. Procura melhorar o valor do flash já presente ao priorizar continuamente os metadados ativos.

Isto estabelece o principal adversário da versão: otimização orientada por software versus expansão liderada por hardware. A IBM aposta que a inteligência de posicionamento pode adiar pelo menos algumas alterações de infraestrutura.

A empresa não elimina a necessidade de planeamento de capacidade. Um nível DB gravemente subdimensionado não consegue reter todos os ficheiros ativos, independentemente de quão bem o software os classifique.

O escalonamento de metadados também não pode corrigir uma rede saturada nem um processador sobrecarregado. Não transformará o armazenamento de objetos em discos rígidos num array totalmente flash para todas as cargas de trabalho.

O seu valor está em evitar desperdícios. Se metadados inativos ocupam suportes rápidos enquanto metadados ativos estão em dispositivos mais lentos, comprar mais hardware trata o sintoma sem corrigir o posicionamento.

A alteração também reforça o argumento da edição empresarial perante operações Ceph de faça-você-mesmo. O Ceph da comunidade permanece aberto e altamente configurável, mas as organizações têm de integrar, validar, monitorizar e suportar a configuração que escolherem.

A IBM fornece código Ceph com versões testadas, interfaces de gestão, processos de atualização, opções de hardware e suporte empresarial. Um gestor automatizado de escalonamento por níveis dá aos compradores outro motivo para comparar a distribuição suportada com implementações mantidas internamente.

Não se trata de um simples conflito entre proprietário e código aberto. O IBM Storage Ceph continua baseado no Ceph, e a IBM contribui para o ecossistema mais amplo.

A verdadeira distinção diz respeito à responsabilidade operacional. Os utilizadores da comunidade podem ajustar sistemas diretamente, enquanto os clientes IBM pagam por um ciclo de vida selecionado e uma implementação suportada.

A Red Hat também oferece tecnologia Ceph empresarial por meio do Red Hat Ceph Storage e integrações de plataforma. A IBM assumiu a responsabilidade por sua oferta Ceph empresarial da Red Hat em 2023, posicionando o Ceph dentro de seu portfólio mais amplo de armazenamento.

Fornecedores tradicionais de armazenamento adotam outra abordagem. Eles frequentemente combinam software proprietário com hardware rigidamente controlado, reduzindo a variação de configurações, mas limitando a flexibilidade de hardware comum.

A IBM ocupa um meio-termo. Ela oferece armazenamento definido por software com suporte, nós validados opcionais e opções de implantação que vão além de um único modelo de appliance.

O gerenciador de desempenho se encaixa bem nessa posição. A IBM pode melhorar o comportamento por meio de software, preservando a escolha de hardware.

A versão 9.9.2 também inclui atualizações graduais sem tempo de inatividade para instâncias do RADOS Gateway. A IBM afirma que novas versões do RGW podem iniciar ao lado das instâncias existentes enquanto as solicitações ativas são concluídas nas versões anteriores.

Esse recurso reforça o argumento operacional. O desempenho importa, mas as empresas também avaliam se a manutenção interrompe aplicações compatíveis com S3.

A versão adiciona controles aprimorados de ciclo de vida para grupos de gateway NVMe/TCP. Os administradores obtêm recursos expandidos de gerenciamento de hosts, acesso, rede e exibição por meio do painel.

Essas mudanças não aceleram diretamente o RocksDB. Elas reduzem o custo administrativo em torno dos serviços de bloco e objeto, o que influencia o valor total de uma distribuição empresarial.

Versões anteriores do Ceph da IBM já buscavam desempenho por outros mecanismos. O Storage Ceph 8.0 incluiu melhorias em snapshots e manteve o backend Crimson como uma prévia de tecnologia.

O Crimson é uma arquitetura OSD mais recente, projetada em torno de processamento assíncrono e eficiência de CPUs modernas. Ele ataca um problema mais amplo de execução de software do que o transbordamento de metadados.

A versão 9.9.0 também habilitou por padrão otimizações de codificação por apagamento para pools recém-criados. A IBM afirma que essas otimizações reduzem o preenchimento e melhoram o comportamento de I/O pequeno em configurações compatíveis.

Essa mudança beneficia cargas de trabalho RBD, CephFS e de objetos que contêm objetos pequenos ou acesso aleatório. Cargas de trabalho de objetos grandes e sequenciais recebem menos benefícios, segundo a orientação de otimização da IBM.

Em conjunto, esses avanços mostram uma estratégia em camadas. A IBM está melhorando a eficiência da proteção de dados, a execução do OSD, o posicionamento de metadados, o gerenciamento de protocolos e os fluxos de trabalho administrativos.

O BlueFS Spillover Cleaner se destaca porque aborda uma incompatibilidade imediata entre armazenamento rápido e lento. Ele promete melhor comportamento sem exigir mudanças nas aplicações.

A questão competitiva agora se torna mensurável. O posicionamento orientado por software consegue oferecer melhoria suficiente para adiar a expansão de hardware, ou apenas suaviza um gargalo limitado?

O que a alegação de desempenho da IBM não mostra

A versão identifica um mecanismo crível, mas a IBM não forneceu dados suficientes para quantificar seu efeito em cargas de trabalho de produção.

Nem o anúncio da IBM nem o relatório inicial incluem resultados de benchmarks padronizados para o BlueFS Spillover Cleaner. Não há comparações publicadas de IOPS, throughput ou latência entre configurações com e sem o recurso habilitado.

A IBM também não fornece uma distribuição de latência de cauda. Essa omissão importa porque um desempenho mais consistente é um dos benefícios declarados.

Médias, por si só, não resolveriam a questão. Os compradores precisam de dados de percentis que mostrem se o recurso reduz operações ocasionalmente lentas após o transbordamento de metadados.

O anúncio não especifica um cluster de teste. Os leitores não podem avaliar tipos de unidade, proporções entre dispositivos DB, velocidades de rede, contagens de OSD, configurações de replicação ou perfis de objetos.

Ele também não separa os efeitos do recurso entre acessos a bloco, arquivo e objeto. Cada serviço impõe demandas diferentes à camada RADOS.

Uma carga de trabalho de máquinas virtuais pode enfatizar operações pequenas e aleatórias de bloco. Um repositório S3 pode conter objetos grandes e sequenciais, enquanto um pipeline de dados pode produzir milhões de arquivos pequenos.

O valor do cleaner pode variar fortemente entre esses casos. Um benchmark focado em um dispositivo DB deliberadamente subdimensionado pode superestimar os benefícios para clusters bem provisionados.

Por outro lado, um teste curto pode subestimar o recurso. A organização automática em camadas precisa de tempo e variação de carga suficientes para reconhecer arquivos ativos e reorganizar o posicionamento.

A movimentação em segundo plano cria outra incerteza. Promoções e rebaixamentos consomem largura de banda de I/O, e a versão não fornece nenhuma medição dessa sobrecarga.

Os administradores devem perguntar como o sistema evita oscilações. Uma carga de trabalho que muda rapidamente pode fazer arquivos alternarem entre camadas, a menos que a política aplique limites estáveis.

Eles também devem examinar o comportamento de recuperação. Clusters Ceph podem gerar intensa atividade interna após falhas de dispositivos ou nós, exatamente quando uma latência previsível se torna importante.

A versão não explica se o cleaner pausa, altera prioridades ou continua movendo arquivos durante a recuperação. Essas decisões podem influenciar tanto o tráfego das aplicações quanto o tempo de reparo.

O comportamento durante atualizações merece atenção semelhante. Implantações existentes precisam saber se o gerenciador inicia automaticamente, exige configuração ou realiza uma redistribuição inicial.

O resumo público da IBM não fornece uma matriz de compatibilidade para todos os layouts históricos. Os compradores devem verificar os pré-requisitos na documentação e testar um cluster representativo antes da ativação em produção.

A capacidade continua sendo um limite rígido. O cleaner pode classificar metadados, mas não pode criar mais espaço DB. Um conjunto de metadados consistentemente ativo maior que o dispositivo rápido ainda sofrerá transbordamento.

A melhoria também pode expor outra restrição. Quando a busca de metadados se torna mais rápida, a saturação da rede ou o processamento da CPU podem limitar os ganhos gerais.

Isso não invalida o projeto da IBM. Define a fronteira em torno da alegação.

O guia de arquitetura do Ceph descreve um sistema distribuído cujo comportamento depende de componentes de armazenamento, rede e software que interagem entre si. Otimizar um caminho não garante uma melhoria equivalente no nível da aplicação.

Portanto, as organizações devem tratar o IBM Storage Ceph 9.9.2 como uma atualização testável, não como substituto para observabilidade. Antes da implantação, as equipes devem registrar a latência de referência, o throughput, a utilização dos dispositivos e as condições de transbordamento.

Elas devem reproduzir cargas de trabalho representativas após a atualização. Os testes devem incluir tráfego em estado estável, mudanças súbitas de carga, compactação do RocksDB, recuperação e operações de manutenção.

As equipes devem comparar a latência por percentis, não apenas as médias. Elas também devem acompanhar quanto dado se move entre os dispositivos DB e SLOW.

Um resultado bem-sucedido mostraria mais metadados ativos permanecendo em mídia rápida sem atividade disruptiva em segundo plano. Também mostraria um benefício no nível da aplicação, não apenas um layout de armazenamento mais limpo.

Benchmarks independentes continuam sendo especialmente importantes para aquisições. A IBM vende o Storage Ceph como software, serviço e uma oferta combinada com hardware validado.

Esses modelos de implantação não produzirão resultados idênticos. Os compradores precisam de evidências de configurações semelhantes aos seus próprios ambientes.

A conclusão cautelosa é direta. A IBM descreveu uma forma tecnicamente plausível de reduzir uma fonte de latência do Ceph, mas a evidência pública para antes de quantificar seu impacto.

Três sinais mostrarão se a melhoria importa

O próximo teste é saber se o mecanismo de posicionamento da IBM produz ganhos repetíveis fora de um anúncio de lançamento.

O primeiro sinal é a publicação de benchmarks. A IBM, parceiros ou testadores independentes devem comparar a versão 9.9.2 com o cleaner habilitado e desabilitado em hardware idêntico.

Testes úteis incluiriam dispositivos de dados em discos rígidos combinados com dispositivos DB NVMe. Eles deveriam apresentar latência média e por percentis, IOPS, throughput, sobrecarga de movimentação e ocupação da camada DB.

Perfis separados devem abranger máquinas virtuais, objetos S3 pequenos, objetos grandes e operações do CephFS intensivas em metadados. Esses resultados fortaleceriam a alegação da IBM se as melhorias permanecerem consistentes em mais de uma carga de trabalho.

Resultados limitados a uma demonstração deliberadamente restrita enfraqueceriam a interpretação mais ampla. Eles ainda poderiam comprovar o mecanismo, mas não seu valor geral em produção.

O segundo sinal é a evidência operacional de clusters atualizados. Os administradores devem observar se arquivos ativos do RocksDB permanecem em dispositivos rápidos após semanas de demanda variável.

Um comportamento estável sustentaria o argumento de otimização por software da IBM. Migrações frequentes, amplificação de escrita inesperada ou ajustes difíceis deslocariam a vantagem para dispositivos DB maiores e layouts estáticos mais simples.

Implantações reais também devem revelar como o cleaner se comporta durante recuperação e compactação. Esses períodos podem distinguir uma política eficaz de outra otimizada para condições limpas de laboratório.

O terceiro sinal é a passagem da IBM da descrição do recurso para orientações detalhadas de ciclo de vida. A documentação deve explicar padrões, limites, métricas de monitoramento, alertas, comportamento de reversão e pré-requisitos de atualização.

Orientações claras indicariam que a IBM espera amplo uso em produção. Documentação limitada sugeriria que os clientes devem avançar por meio de implantações acompanhadas de perto.

As respostas de concorrentes e da comunidade upstream importam, mas são secundárias. A evidência decisiva virá de dados de desempenho e experiência operacional, não de comparações de marketing.

Os clientes também devem acompanhar o trabalho contínuo da IBM no Crimson. A organização em camadas de metadados melhora o posicionamento de arquivos, enquanto o Crimson visa a eficiência dentro do caminho de software do OSD.

Se ambos amadurecerem com sucesso, a IBM poderá argumentar que os limites de desempenho do Ceph são cada vez mais solucionáveis por software. Isso fortaleceria sua posição contra a expansão centrada em hardware e sistemas de armazenamento proprietários.

As otimizações de codificação por apagamento fornecem outro ponto de referência. Elas mostram que a IBM já está mudando o comportamento padrão onde acredita que os ganhos de eficiência estão maduros o suficiente para novos pools.

O BlueFS Spillover Cleaner só conquistará confiança semelhante depois que os clientes entenderem seu comportamento sob carga sustentada. O posicionamento automático deve permanecer previsível quando o hardware falha ou a demanda muda repentinamente.

A lição mais ampla vai além do Ceph. Sistemas modernos de armazenamento dependem cada vez mais de pequenas camadas de mídia rápida que coordenam pools de capacidade muito maiores.

Gerenciar bem essa camada rápida pode importar tanto quanto seu tamanho nominal. Um posicionamento ruim desperdiça flash, enquanto uma movimentação descontrolada pode criar seu próprio custo de desempenho.

O IBM Storage Ceph acelera o desempenho do cluster ao transformar o posicionamento de metadados em um processo ativo. Essa é uma mudança arquitetural significativa, mesmo sem um benchmark de destaque.

No entanto, a arquitetura é apenas o início da decisão de compra. As equipes empresariais precisam saber quanto a latência cai, quais cargas de trabalho se beneficiam e qual custo operacional acompanha a movimentação.

A versão oferece aos administradores um experimento concreto. Identificar clusters com transbordamento do BlueFS, estabelecer uma referência, atualizar um ambiente controlado e observar tanto a latência da aplicação quanto a atividade em segundo plano.

Se o cleaner promover consistentemente os arquivos certos, a IBM terá mostrado que o software pode recuperar desempenho do armazenamento híbrido existente. Se os ganhos permanecerem restritos, a expansão de hardware manterá seu papel conhecido.

Por enquanto, o IBM Storage Ceph 9.9.2 merece atenção porque visa um gargalo específico com um mecanismo coerente. O próximo passo pertence aos operadores e testadores independentes.

Os clusters reais confirmarão que o posicionamento automatizado de metadados adia a próxima compra de hardware, ou revelarão que o gargalo simplesmente se desloca para outro lugar?