Linus Torvalds y el sistema de archivos OS X

Una transcripción de la sesión "Q & A" en la que Linus hizo el comentario está disponible, pero parece que no se le pidió que explicara más detalles. No estoy seguro de si un análisis más profundo de su opinión sobre HFS + se ha escrito en otra parte.

Para el análisis de otra persona del asunto, puedes echar un vistazo a las reseñas de Mac OS X de John Siracusa. En particular el de Mac OS X Lion, que tiene una sección titulada " Lo que está mal con HFS + ". Creo que lo más importante es (énfasis mío):

  

La concurrencia, los metadatos escritos en el orden de bytes correcto, la precisión de la fecha por debajo del segundo, la compatibilidad con tamaños de volumen masivos y la compatibilidad con archivos dispersos son características comunes de los sistemas de archivos Unix. Mac OS X, por supuesto, está construido sobre una base Unix. Cuando se trasladó HFS + del Mac OS clásico a Mac OS X, era necesario ampliarlo para admitir algunos conjuntos mínimos de funciones que se esperan de los sistemas de archivos Unix .

     

Algunas de estas características fueron fáciles de ajustar, pero otras fueron muy difíciles de agregar al sistema de archivos sin romper la compatibilidad hacia atrás. Un ejemplo particularmente aterrador es la implementación de enlaces duros en HFS +. Para realizar un seguimiento de los enlaces duros, HFS + crea un archivo separado para cada enlace dentro de un directorio oculto en el nivel raíz del volumen. Los directorios ocultos son un poco espeluznantes para comenzar, pero el verdadero susto se produce cuando recuerdas que Time Machine se implementa utilizando enlaces duros para evitar la duplicación innecesaria de datos.

El punto importante aquí es que Mac OS X utiliza un sistema de archivos que ni siquiera fue diseñado para un sistema Unix, fue diseñado para Mac OS clásico y parcheado para implementar las características de Mac OS X 10.0 mientras mantiene la compatibilidad con versiones anteriores . Apple ha implementado posteriormente las funciones adicionales que ahora tiene en Mac OS X 10.7 (registro en diario, metadatos, eventos del sistema de archivos ...) utilizando el mismo enfoque de parches en lugar de un enfoque de "diseño desde cero". No estoy seguro de cómo explicar esto de forma no técnica, pero se podría decir que todas estas características adicionales se basan en una base clásica de Mac OS que nunca fue diseñada para admitirlas. Esto significa que la solución no es tan buena como podría ser. El ejemplo que Siracusa continúa discutiendo es que la solución que Apple tuvo que usar para los enlaces duros mientras trabajaba dentro de las limitaciones de HFS + es demasiado sensible a los fallos de hardware, lo que se complica por el hecho de que HFS + nunca fue diseñado para preocuparse por los datos. integridad. Por supuesto, mantener la compatibilidad con el Mac OS clásico era una limitación deseable en Mac OS X 10.0, pero en realidad ya no lo es en Mac OS X 10.7.

Aunque no soy un experto en sistemas operativos, y acabo de comenzar a usar OSX después de venir de Windows, me considero un PowerUser en Windows y bastante competente en Linux. En este contexto, me ha sorprendido que en un sistema operativo bastante moderno como OSX, el sistema de archivos tenga características como la forma en que los nombres de los archivos se "amontonan".

Entiendo que los problemas de Linus con HFS + se derivan del mismo punto: por lo que he encontrado al investigar el problema, HFS + almacena los nombres de los archivos usando Unicode, pero cuando un archivo usa caracteres "extendidos" o NO ASCII ( como á, é, í, ó, ú, ñ del español o cosas como ü en alemán), para lo cual Unicode proporciona 2 formas de codificar el nombre, OSX silenciosamente "normaliza" la codificación en el momento del almacenamiento ... No es real se produce un error cuando el archivo se ha creado y consumido en OSX, pero cuando se comparte información con usuarios de otros sistemas operativos, el hecho de que el nombre del archivo cambie hace que surja todo tipo de comportamientos extraños. ..

Caso en cuestión: he estado rastreando mis "artefactos" (archivos, documentos, etc.) de mi trabajo en Subversion durante los últimos 8 años. Cuando me mudé a Mac, obtuve el cliente SVN para Mac y, después de realizar un Checkout de mis directorios relevantes, encontré que faltan todos los archivos que que tienen acentos, y que falta un nuevo archivo con el mismo el nombre aparece como no versionado. Al analizarlo, el problema es que el archivo IN del sistema de archivos está codificado en Apple, mientras que los datos en el repositorio utilizan otra codificación Unicode (perfectamente válida y legítima) ...

Esto, creo, es una "manía" burda de mis datos. Apple SÍ entiende ambos formatos de la codificación del nombre de archivo (acceder a un recurso compartido en Windows o usar una memoria USB desde Windows muestra los nombres de archivo correctos, etc.) pero en el momento de la creación del archivo, se decide "sabe mejor" y simplemente cambió el nombre de los archivos. ..

Nuevamente, no es algo que la mayoría de los usuarios notarán, hasta que hagan una copia de un archivo, o le cambien el nombre, y lo vuelvan a colocar donde estaba el original y terminen con dos archivos que aparentemente son iguales !!!)

John Siracusa & Dan Benjamin discute algunas desventajas de HFS + en Hypercritical # 56 .

Tratan la corrupción de datos en HFS + y consideran algunas de las características de ZFS.