quarta-feira, 22 de junho de 2016

Apple File System

APFS in Detail: Overview (Adam Leventhal's blog)
Introducing Apple File System (WWDC16, PDF)

Boa notícia. Já estava mais do que na hora de um substituto para o HFS+ aparecer. A Apple pretende colocá-lo em produção em 2017. Será tempo recorde, levando com conta que é um sistema de arquivos desenvolvido do zero a partir de 2014. Sistemas de arquivos precisam de pelo menos dez anos para amadurecerem, diz o provérbio.

quarta-feira, 15 de junho de 2016

Assinaturas

Quando formatamos um dispositivo de armazenamento, colocamos um sistema arquivos numa região delimitada. Às ferramentas que os criam, precisamos dizer qual área compreenderá essa região. Tradicionalmente, especificamos um dispositivo de bloco como /dev/sdc1.

Imagine um disco de 2 MiB (2097152 bytes) com setores de 512 bytes (4096 setores), particionamento MBR (MS-DOS) e uma única partição primária.

    Disco
    /dev/sdc
    +----------------------------------------------------------------------------+
    |                   Espaço não                                               |
    |                   particionado                                             |
    |   +--------------+  /      \  +----------------------------------------+   |
    |   | MBR, tabela  |            | Partição 1                             |   |
    |   | de partições |            | /dev/sdc1                              |   |
    |   |              |            |                                        |   |
    |   +--------------+            +----------------------------------------+   |
LBA |   0              1           / 2048                               4095 /   |
    |                             /                                         /    |
    +----------------------------/-----------------------------------------/-----+
                                /                                         /
                                +----------------------------------------+
                                |                                        |
                                |                                        |
                                |                                        |
                                +----------------------------------------+
                                0                                      2047

(fora de escala)

O kernel interpreta a tabela de partições do disco /dev/sdc e cria o dispositivo /dev/sdc1 [1], que corresponde à área entre os setores 2048 e 4095 neste exemplo. Quando um programa acessar o setor 0 de /dev/sdc1, estará na verdade acessando o setor 2048 do disco. Da mesma forma, o último setor de /dev/sdc1 (2047) equivale ao setor 4095 do disco. Essa tradução é feita automaticamente pelo kernel.

Portanto, ao rodarmos mkfs.ext4 /dev/sdc1, dizemos ao programa para criar um sistema de arquivos EXT4 entre os setores 2048 e 4095 do disco. O resto fica intocado.

Cada sistema de arquivos possui alguns bytes em posições específicas (assinaturas) que os identificam. À medida que sobre uma mesma área criamos diferentes sistemas de arquivos, é prudente, a cada formatação, apagar assinaturas anteriores eventualmente presentes. Ter mais de uma assinatura numa mesma área é roleta russa, pois o volume pode, se por azar o offset conferir, ser montado com o driver de outro sistema de arquivos (colisão), que por sua vez pode considerá-lo inconsistente e na pior das hipóteses tentar consertá-lo sobrescrevendo setores e causando perda de dados no sistema arquivos verdadeiro. Idem com as ferramentas de verificação (fsck).

Na libblkid, parte da suíte util-linux, há funções de detecção e apagamento de assinaturas, e um extenso banco de dados contendo várias delas, que podem ser usadas por outros programas. O wipefs, da própria suíte, é um consumidor dessas interfaces. Idealmente, todos os mkfs deveriam linkar a libblkid e usá-la com essa finalidade, mas nem todos o fazem.

quarta-feira, 8 de junho de 2016

Firefox 49 requererá SSE2

Snif, snif, não poderei mais rodar o Firefox no Windows ☹

Espantoso assombrações como Athlon XP, Duron e afins ainda terem influência em softwares atuais. SSE2 é suportado desde o Athlon 64 (K8, 2003) e Pentium 4 (Willamette, 2000).

O Visual C++ 2015 (compilador C/C++ do Visual Studio, vulgo MSVC) tem um bug que, em x86-32, emite instruções SSE mesmo quando configurado para não fazê-lo (/arch:IA32). Esse bug acendeu a discussão sobre o assunto. Para o Firefox 48, voltarão ao VS2013 temporariamente, cujos binários produzidos, devido à configuração da Mozilla, continuarão rodando em máquinas sem nem mesmo SSE!

No ciclo do Firefox 49, colocarão o VS2015 de volta e nas compilações x86-32 trocarão /arch:IA32 por /arch:SSE2 (que, a propósito, é padrão a partir do VS2012). O instalador do Firefox 49 será modificado para não prosseguir ao detectar processador sem SSE2. A infraestrutura de atualização funcionará assim: instalações anteriores precisarão atualizar obrigatoriamente para a versão 48 primeiro, que estará apta a detectar quais instruções adicionais são suportadas, de forma a oferecer ou não versões posteriores. Máquinas sem SSE2 ficarão na versão 48 para sempre. Restará para esse pessoal rodar a versão 45 ESR enquanto for suportada (idem com o Thunderbird).

Em x86-64, SSE2 é sempre presente pois faz parte do conjunto base de instruções da arquitetura. /arch:SSE2 não tem efeito na versão x86-64 do MSVC. Nela, é possível apenas habilitar geração de código com instruções AVX (/arch:AVX) ou AVX2 (/arch:AVX2).

Ganho de desempenho do navegador em x86-32 com /arch:SSE2 é de até 18%.

No Linux a situação está indefinida. As distribuições possuem política que define globalmente o conjunto de instruções requerido por todos os pacotes do repositório. Será improvável aceitarem o Firefox x86-32 requerendo SSE2, a menos que uma cirurgia downstream para isso seja complexa e torne a manutenção do pacote um inferno, como aconteceu com o Chromium no Debian.

quinta-feira, 2 de junho de 2016

Flatpak

Este é um projeto absolutamente fundamental:

Flatpak - the future of application distribution

É o antigo xdg-app (antes GNOME Apps), sobre o qual comentei anos atrás. Não existe a mais mínima chance do GNU/Linux vingar em dispositivos que não sejam embarcados ou servidores sem algo assim, que facilite a distribuição de programas e seja independente da estrutura de empacotamento convencional (DEB, RPM, etc.). É similar ao Snappy da Canonical, com a vantagem de não requerer assinatura de contributor licence agreement nas contribuições de código. Não recomendo a ninguém doar código para qualquer empresa/entidade que seja. No fim, quem perde é quem exige-o.