Linus Torvalds e o sistema de arquivos OS X

Em 2008, Linus Torvalds disse famosa em uma entrevista que "o OS X, de certa forma, é pior do que o Windows para programar. O sistema de arquivos deles é completo e uma porcaria total, o que é assustador". Procurei mais detalhes sobre por que ele se sente assim sobre o sistema de arquivos OS X (HFS + presumivelmente), mas não consegui encontrar nada.

Linus certamente não gosta do modelo básico de sistema de arquivos Unix, e duvido que ele odeie o HFS + por não fazer distinção entre maiúsculas e minúsculas. E, apesar de quão provocador é o seu comentário, duvido que seja completamente sem mérito. Como o comentário foi no contexto de programação do OS X, suspeito que sua opinião possa ter sido baseada em desempenho, robustez, interface do sistema operacional ou algo do tipo. Alguém sabe que reclamações a Linus da era de 2008 poderia ter tido com a HFS + da era de 2008?

Está disponível uma transcrição da sessão de perguntas e respostas na qual Linus fez o comentário , mas parece que ele não foi convidado a elaborar. Não tenho certeza se uma análise mais aprofundada de sua opinião sobre o HFS + foi anotada em outro lugar.

Para a análise de outra pessoa, você pode dar uma olhada nas revisões do Mac OS X de John Siracusa. Em particular a do Mac OS X Lion, que possui uma seção intitulada " O que há de errado com o HFS + ". Acho que o mais importante é (ênfase minha):

Simultaneidade, metadados escritos na ordem correta dos bytes, precisão de menos de um segundo, suporte para tamanhos de volume massivos e suporte a arquivos esparsos são recursos comuns dos sistemas de arquivos Unix. O Mac OS X, é claro, é construído sobre uma base Unix. Quando o HFS + foi portado do Mac OS clássico para o Mac OS X, ele precisava ser estendido para suportar alguns conjuntos mínimos de recursos esperados dos sistemas de arquivos Unix .

Alguns desses recursos eram fáceis de ajustar, mas outros eram muito difíceis de adicionar ao sistema de arquivos sem quebrar a compatibilidade com versões anteriores. Um exemplo particularmente assustador é a implementação de links físicos no HFS +. Para acompanhar os links físicos, o HFS + cria um arquivo separado para cada link físico dentro de um diretório oculto no nível raiz do volume. Diretórios ocultos são meio assustadores para começar, mas o verdadeiro susto ocorre quando você se lembra que o Time Machine é implementado usando links físicos para evitar duplicação desnecessária de dados.

O ponto importante aqui é que o Mac OS X está usando um sistema de arquivos que nem foi projetado para um sistema Unix, foi projetado para o Mac OS clássico e corrigido para implementar os recursos do Mac OS X 10.0, mantendo a compatibilidade com versões anteriores. A Apple implementou posteriormente os recursos adicionais que agora possui no Mac OS X 10.7 (registro no diário, metadados, eventos do sistema de arquivos ...) usando a mesma abordagem de correção em vez de uma abordagem de "design desde o início". Não sei como explicar isso de maneira não técnica, mas você poderia dizer que todos esses recursos adicionais estão baseados em uma base clássica do Mac OS que nunca foi projetada para dar suporte a eles. Isso significa que a solução não é tão boa quanto poderia ser. O exemplo que Siracusa continua discutindo é que a solução que a Apple teve que usar para links físicos enquanto trabalhava dentro das limitações do HFS + é muito sensível a falhas de hardware, o que é agravado pelo fato de que o HFS + também nunca foi projetado para se preocupar com dados integridade. Obviamente, manter a compatibilidade com o Mac OS clássico era uma limitação desejável no Mac OS X 10.0, mas não existe mais no Mac OS X 10.7.

Embora eu não seja um especialista em sistemas operacionais e comecei a usar o OSX depois de vir do Windows, considero-me um PowerUser no Windows e bastante competente no Linux. Vindo desse contexto, fiquei surpreso que, em um sistema operacional bastante moderno como o OSX, o sistema de arquivos tenha peculiaridades como a maneira como os nomes dos arquivos são "misturados".

Entendo que os problemas de Linus com o HFS + decorrem do mesmo ponto: pelo que encontrei pesquisando o problema, o HFS + armazena os nomes dos arquivos usando Unicode, mas quando um arquivo usa caracteres "estendidos" ou NÃO ASCII (como á, é, í, ó, ú, ñ do espanhol ou coisas como o ü em alemão), para o qual o Unicode fornece 2 maneiras de codificar o nome, o OSX silenciosamente "normaliza" a codificação no tempo de armazenamento ... Não é um problema real quando o O arquivo foi criado e consumido no OSX, mas quando você compartilha informações com usuários de outros sistemas operacionais, o fato de o nome do arquivo ser alterado gera todos os tipos de comportamentos estranhos ...

Caso em questão: tenho acompanhado meus "artefatos" de trabalho (arquivos, documentos, etc.) no Subversion nos últimos 8 anos. Ao migrar para o Mac, obtive o cliente SVN para Mac e, depois de fazer um checkout dos meus diretórios relevantes, descobri que todos os arquivos com sotaque parecem estar ausentes e um novo arquivo com o mesmo nome aparece sem versão. Indo além, o problema é que o arquivo IN do sistema de arquivos é codificado por apple, enquanto os dados no repositório usam outra codificação Unicode (perfeitamente válida e legítima) ...

Acho que isso é uma "manipulação" grosseira dos meus dados. A Apple entende os dois formatos da codificação de nome de arquivo (acessar um compartilhamento no Windows ou usar um pendrive no Windows mostra os nomes de arquivos adequados etc.), mas no momento da criação do arquivo, é decidido que "ele conhece melhor" e apenas renomeou os arquivos. ..

Novamente, não é algo que a maioria dos usuários notará - até fazer uma cópia de um arquivo ou renomeá-lo e colocá-lo de volta onde estava o original e acabar com dois arquivos aparentemente iguais !!!)

John Siracusa e Dan Benjamin discutem algumas desvantagens do HFS + no Hypercritical # 56 .

Eles abordam a corrupção de dados no HFS + e consideram alguns dos recursos do ZFS.