No mês passado, foram divulgados os planos para o Fedora Cloud 35 usar o sistema de arquivos Btrfs por padrão, semelhante ao Fedora Workstation usando Btrfs por padrão para várias versões. Esse plano já foi assinado pela FESCo permitindo que essa mudança aconteça. Portanto, o Fedora Cloud 35 vai usar Btrfs por padrão após esta aprovação.
Os desenvolvedores do Fedora, juntamente com os engenheiros da Amazon, Facebook e outros, optaram por usar o Btrfs por padrão com o Fedora Cloud. Entre os recursos do Btrfs de interesse para o pessoal do Fedora Cloud estão:
- compactação transparente do sistema de arquivos;
- recursos de cópia na gravação (CoW), reflinks e instantâneos;
- maior integridade de dados;
- redução e aumento on-line;
- e os outros atributos geralmente alardeados quando falamos sobre Btrfs.
Fedora Cloud 35 vai usar Btrfs por padrão
Todos os detalhes técnicos sobre seus planos para usar o Btrfs por padrão com o Fedora Cloud são apresentados nesta página do Wiki.
Na terça-feira, o Comitê de Engenharia e Direção do Fedora (FESCo) assinou o trabalho deste recurso, permitindo assim que prossiga e aconteça para o lançamento neste final de ano, assumindo que os desenvolvedores não encontrem nenhum obstáculo técnico que impeça o recurso de ser realizado a tempo.
SUSE Linux Enterprise e openSUSE Leap
O sistema operacional openSUSE Tumbleweed de lançamento contínuo analisa os níveis de recursos HWCAPS/x86-64 para poder fornecer maior desempenho pronto para uso, carregando seletivamente mais bibliotecas ajustadas dependendo da CPU em uso. Então, a partir de agora, o SUSE Linux Enterprise e openSUSE Leap também estão procurando oferecer uma funcionalidade semelhante que pode aparecer a tempo para o próximo lançamento/service pack.
Na mesa do openSUSE Leap 15.4/SUSE Linux Enterprise 15 SP4 está oferecendo bibliotecas habilitadas para x86_64-v2 de pacotes importantes do sistema básico. Os desenvolvedores admitem, entretanto, que isso pode não acontecer até a segunda atualização, Leap 15.5/SUSE Linux Enterprise 15 SP5, dado o trabalho pela frente.
Os últimos lançamentos GCC e Clang suportam a noção de níveis de recursos de microarquitetura x86-64 e Glibc 2.33 adicionou os bits HWCAPS para em tempo de execução ser capaz de carregar dinamicamente bibliotecas mais otimizadas para a determinada CPU sendo usada onde houver tal biblioteca presentes no sistema. Este trabalho pode permitir que distribuições Linux forneçam pacotes mais otimizados que permitiriam o uso de AVX e outras extensões de conjunto de instruções mais recentes sem aumentar o requisito básico para todos os usuários.
Várias distribuições do Linux têm procurado usar os níveis de recursos da microarquitetura HWCAPS/x86-64 e, para o openSUSE Leap/SUSE Linux Enterprise, eles o são, pelo menos, para bibliotecas importantes do sistema.
Mais detalhes
O nível de recurso x86_64-v2 que o openSUSE Leap/SLE está buscando assume que a CPU pode lidar com SSE4.2, SSSE3, POPCNT e CMPXCHG16B. A maioria das CPUs nos últimos anos pode suportar pelo menos x86_64-v2 – basicamente CPUs que remontam aos dias do Intel Nehalem. É com v3 e superior que o suporte fica um pouco mais complicado devido à necessidade de AVX2.
O x86_64-v2 HWCAPS para bibliotecas de componentes importantes do sistema básico atualmente faz parte do planejamento de recursos para o próximo lançamento SLE/Leap e, com sorte, isso acontecerá sem a necessidade de deslizar para outro ciclo.
Enquanto isso, o Red Hat Enterprise Linux 9 exigirá x86_64-v2 em superar o próprio requisito básico, em vez de apenas usar o HWCAPS lá. Portanto, veremos se virá o SUSE Linux Enterprise 16 se o SUSE fizer uma mudança semelhante apenas para exigir isso e, possivelmente, oferecer HWCAPS para -v3 ou -v4. Em qualquer caso, pelo menos mais distribuições Linux estão começando a olhar para HWCAPS e outras considerações x86_64 em nome de um melhor desempenho pronto para uso.
