Linus Torvalds et le système de fichiers OS X

28

En 2008, Linus Torvalds a déclaré dans une interview que "OS X est en quelque sorte pire que Windows à programmer. Leur système de fichiers est complet et complètement nul, ce qui est effrayant." J'ai cherché plus de détails sur les raisons pour lesquelles il ressent ce point de vue sur le système de fichiers OS X (HFS + probablement), mais je n'ai rien trouvé.

Linus n'aime certainement pas le modèle de base du système de fichiers Unix, et je doute qu'il déteste HFS + pour être insensible à la casse. Et malgré la façon dont son commentaire est provocateur, je doute que ce soit complètement sans mérite. Étant donné que le commentaire était dans le contexte de la programmation pour OS X, je soupçonne que son opinion peut être basée sur les performances, la robustesse, l'interface du système d'exploitation ou quelque chose du genre. Quelqu'un sait-il quelles plaintes Linus de l'ère 2008 pourrait avoir eu avec le HFS + de l'ère 2008?

macos filesystem

— Kenster
source

2

Il est connu pour avoir des opinions très fortes sur certaines choses, par exemple lorsqu'il a parlé de git @ google, il a passé une bonne partie de la discussion à jeter les autres systèmes. Je dirais donc qu'il a probablement une raison de croire ce qu'il pense, mais c'est aussi une personne très exagérée, même s'il est un génie. youtube.com/watch?v=4XpnKHJAok8

— El Developer

3

Si vous n'obtenez pas ici la réponse à cette question que vous espériez, vous pouvez également envisager de rechercher (et éventuellement de demander également) sur Unix & Linux ou Super User . (Avec autant de sites disponibles maintenant, il est parfois difficile de savoir quel est l' endroit pour poser une question. Au moins à mon humble avis. :)

— irrationnel John

J'ai tendance à me battre avec HFS + plus que tout autre système de fichiers que je rencontre normalement. De nos jours, sur la plupart des systèmes, je n'ai pas l'impression de remarquer ou de me soucier du système de fichiers qu'il utilise, mais HFS + propose toujours quelque chose. Tout comme aujourd'hui, j'ai trouvé que j'étais vissé par son manque de résolution inférieure à la seconde pour les modtimes. Il y a aussi eu le temps où j'ai trouvé deux lignes de code C qui pouvaient provoquer un blocage dans le système de fichiers, faisant pratiquement tomber la machine entière. Ce n'était même pas corrigé à partir de 10,5. Pas sûr des versions plus récentes.

— Iguananaut

21

Une transcription de la session «Q&A» au cours de laquelle Linus a fait le commentaire est disponible, mais il semble qu'il n'ait pas été invité à élaborer. Je ne sais pas si une analyse plus approfondie de son opinion sur HFS + a été écrite ailleurs.

Pour l'analyse de la question par quelqu'un d'autre, vous pouvez consulter les critiques de Mac OS X de John Siracusa. En particulier celui pour Mac OS X Lion qui a une section intitulée " Qu'est-ce qui ne va pas avec HFS + ". Je pense que le bit le plus saillant est (soulignement le mien):

La simultanéité, les métadonnées écrites dans le bon ordre d'octets, la précision de la date inférieure à la seconde, la prise en charge de volumes de volumes massifs et la prise en charge de fichiers clairsemés sont toutes des caractéristiques courantes des systèmes de fichiers Unix. Mac OS X, bien sûr, est construit sur une fondation Unix. Lorsque HFS + a été porté de Mac OS classique à Mac OS X, il a dû être étendu pour prendre en charge un ensemble minimal de fonctionnalités attendues des systèmes de fichiers Unix .

Certaines de ces fonctionnalités étaient faciles à installer, mais d'autres étaient très difficiles à ajouter au système de fichiers sans rompre la compatibilité descendante. Un exemple particulièrement effrayant est l'implémentation de liens durs sur HFS +. Pour garder une trace des liens durs, HFS + crée un fichier séparé pour chaque lien dur dans un répertoire caché au niveau racine du volume. Les répertoires cachés sont plutôt effrayants pour commencer, mais la vraie peur vient quand vous vous souvenez que Time Machine est implémenté à l'aide de liens durs pour éviter la duplication inutile des données.

Le point important ici est que Mac OS X utilise un système de fichiers qui n'a même pas été conçu pour un système Unix, il a été conçu pour Mac OS classique et corrigé pour implémenter les fonctionnalités de Mac OS X 10.0 tout en maintenant la compatibilité descendante. Apple a par la suite implémenté les fonctionnalités supplémentaires dont il dispose désormais dans Mac OS X 10.7 (journalisation, métadonnées, événements de système de fichiers ...) en utilisant la même approche de correction plutôt qu'une approche de «conception à partir de zéro». Je ne sais pas comment expliquer cela de manière non technique, mais vous pourriez dire que toutes ces fonctionnalités supplémentaires reposent sur une fondation Mac OS classique qui n'a jamais été conçue pour les prendre en charge. Cela signifie que la solution n'est pas aussi bonne qu'elle pourrait l'être. L'exemple que Siracusa poursuit en discutant est que la solution qu'Apple a dû utiliser pour les liens durs tout en travaillant dans les limites de HFS + est trop sensible aux pannes matérielles, ce qui est aggravé par le fait que HFS + n'a jamais été conçu pour se préoccuper des données intégrité. Bien sûr, le maintien de la compatibilité avec Mac OS classique était une limitation souhaitable dans Mac OS X 10.0 mais ce n'est vraiment plus le cas dans Mac OS X 10.7.

— Rinzwind
source

1

Excellent lien; qui couvre beaucoup de choses importantes. Le manque de prise en charge de fichiers clairsemés est assez fou. Linux ext2 a fait des fichiers clairsemés même avec une allocation basée sur un bitmap simple, comme les utilisations HFS +. Je pense cependant qu'il fait trop l'affaire de stocker des métadonnées en big-endian. L' bswapinstruction x86 est très rapide. Cela rend le code plus gros et plus laid, mais le maintien de la compatibilité sur le disque est un gros problème. Linux XFS stocke toujours toutes les métadonnées big-endian (sauf native-endian dans le journal), en raison de son origine chez SGI sur les CPU MIPS. Ce n'est pas une situation idéale, mais XFS n'est pas retenu par elle.

— Peter Cordes

7

Bien que je ne sois pas un expert du système d'exploitation et que je viens de commencer à utiliser OSX après être venu de Windows, je me considère comme un PowerUser sous Windows et assez compétent sous Linux. Venant de ce contexte, j'ai été surpris de constater que dans un système d'exploitation assez moderne comme OSX, le système de fichiers a des bizarreries telles que la façon dont les noms des fichiers sont "mungled".

Je comprends que les problèmes de Linus avec HFS + proviennent du même point: d'après ce que j'ai trouvé en recherchant le problème, HFS + stocke les noms des fichiers en utilisant Unicode, mais quand un fichier utilise des caractères "étendus" ou NON ASCII (comme á, é, í, ó, ú, ñ de l'espagnol ou des choses comme le ü en allemand), pour lesquels Unicode fournit 2 façons de coder le nom, OSX "normalise" silencieusement le codage au moment du stockage ... Pas un vrai problème lorsque le Le fichier a été créé et consommé dans OSX, mais lorsque vous partagez des informations avec des utilisateurs d'autres systèmes d'exploitation, le fait que le nom du fichier change, entraîne toutes sortes de comportements étranges ...

Exemple: j'ai suivi mes "artefacts" de travail (fichiers, documents, etc.) dans Subversion au cours des 8 dernières années. Lors du passage à Mac, j'ai obtenu le client SVN pour Mac, et après avoir effectué une vérification de mes répertoires pertinents, j'ai constaté que tous les fichiers qui avaient des accents semblaient manquer, et un nouveau fichier avec le même nom apparaît comme non versionné. En creusant, le problème est que le fichier DANS le système de fichiers est encodé par Apple, tandis que les données dans le référentiel utilisent un autre encodage Unicode (parfaitement valide et légitime) ...

C'est, je pense, une grossière "mutilation" de mes données. Apple comprend les deux formats d'encodage du nom de fichier (accéder à un partage dans Windows ou utiliser une clé USB à partir de Windows affiche les noms de fichiers appropriés, etc.) mais au moment de la création du fichier, il est décidé "qu'il sait mieux" et renomme simplement les fichiers. ..

Encore une fois, la plupart des utilisateurs ne remarqueront rien - jusqu'à ce qu'ils fassent une copie d'un fichier, ou le renomment, et le remettent à l'endroit où se trouvait l'original et se retrouvent avec deux fichiers qui sont apparemment les mêmes !!!)

— JJarava
source

1

Ce n'est qu'un point, et le vrai problème est que différents systèmes d'exploitation normalisent simplement les chaînes de différentes manières, et les applications multiplates-formes ne traitent pas cela. Ne pas normaliser les noms serait probablement pire (vous pourriez avoir deux fichiers différents avec des noms normalisés sur la même chaîne, sous OS X).

— Blaisorblade

4

John Siracusa et Dan Benjamin discutent de certains inconvénients de HFS + dans Hypercritical # 56 .

Ils corrigent la corruption de données dans HFS + et prennent en compte certaines des fonctionnalités de ZFS.

— badams
source

9

Existe-t-il un moyen de fournir un résumé de leur discussion dans votre réponse? Le flux audio est (à ce stade de notre technologie actuelle) non consultable et très long. Sans oublier que c'est sur un autre site, il est donc susceptible de lier la pourriture. Ce serait une bien meilleure réponse si elle contenait des détails spécifiques sur leur discussion.

— Ian C.

1

La conférence sur le système de fichiers commence dans 23 minutes.

— neoneye

1

La plupart des informations disponibles dans le podcast peuvent également être trouvées dans un article d' Ars Technica de John Siracusa (l'un des deux hommes du podcast.)

— TML