Linus Torvalds y el sistema de archivos OS X


28

En 2008, Linus Torvalds dijo en una entrevista que "OS X de alguna manera es realmente peor que Windows para programar. Su sistema de archivos es completo y una mierda absoluta, lo que da miedo". He buscado más detalles sobre por qué se siente así con respecto al sistema de archivos OS X (HFS + presumiblemente) pero no he podido encontrar nada.

A Linus seguramente no le desagrada el modelo básico del sistema de archivos Unix, y dudo que odie a HFS + por no ser sensible a mayúsculas y minúsculas. Y a pesar de lo provocativo de su comentario, dudo que sea completamente sin mérito. Dado que el comentario fue en el contexto de la programación para OS X, sospecho que su opinión puede haberse basado en el rendimiento, la solidez, la interfaz del sistema operativo o algo por el estilo. ¿Alguien sabe qué quejas que Linus de la era de 2008 podría haber tenido con HFS + de la era de 2008?


2
Se le conoce por tener opiniones realmente fuertes sobre algunas cosas, por ejemplo, cuando dio una charla sobre git @ google, pasó buena parte de la charla destrozando los otros sistemas. Entonces diría que probablemente tiene una razón para creer lo que piensa, pero también es una persona muy exagerada, a pesar de que es un genio. youtube.com/watch?v=4XpnKHJAok8
El Developer

3
Si no obtiene la respuesta a esta pregunta aquí que esperaba, entonces también podría considerar buscar (y posiblemente también preguntar) en Unix & Linux o Super User . (Con tantos sitios disponibles ahora a veces es difícil saber cuál es el lugar para hacer una pregunta, al menos en mi humilde opinión :)..
irracional John

Tiendo a toparse con HFS + más que cualquier otro sistema de archivos que normalmente encuentro. En la actualidad, en la mayoría de los sistemas, no siento que, por lo general, me doy cuenta o me importa qué sistema de archivos está usando, pero HFS + siempre presenta algo. Al igual que hoy, descubrí que me estaba jodiendo por su falta de resolución por debajo de los segundos para modtimes. También hubo un momento en el que encontré dos líneas de código C que podrían causar un punto muerto en el sistema de archivos que prácticamente derrumbaría toda la máquina. Eso ni siquiera se solucionó a partir de 10.5. No estoy seguro acerca de las versiones más recientes.
Iguananaut

Respuestas:


21

Una transcripción de la sesión de "Preguntas y respuestas" en la que Linus hizo el comentario está disponible, pero parece que no se le pidió que diera más detalles. No estoy seguro de si se ha escrito un análisis más profundo de su opinión sobre HFS + en otro lugar.

Para el análisis de otra persona sobre el asunto, puede echar un vistazo a las revisiones de Mac OS X de John Siracusa. En particular, el de Mac OS X Lion, que tiene una sección titulada " ¿Qué tiene de malo HFS + ?". Creo que el bit más destacado 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 HFS + fue portado de Mac OS clásico a Mac OS X, necesitaba extenderse para admitir un conjunto mínimo de características que se esperan de los sistemas de archivos Unix .

Algunas de esas características se ajustaban fácilmente, pero otras eran muy difíciles de agregar al sistema de archivos sin romper la compatibilidad con versiones anteriores. 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 duro dentro de un directorio oculto en el nivel raíz del volumen. Los directorios ocultos son un poco espeluznantes para empezar, pero el verdadero susto llega 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 está utilizando 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 manteniendo la compatibilidad con versiones anteriores. Posteriormente, Apple implementó las características adicionales que ahora tiene en Mac OS X 10.7 (registro en diario, metadatos, eventos del sistema de archivos ...) utilizando el mismo enfoque de parcheo en lugar de un enfoque de "diseño desde cero". No estoy seguro de cómo explicar esto de manera 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 continúa discutiendo Siracusa 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 fallas de hardware, lo que se agrava por el hecho de que HFS + tampoco fue diseñado para preocuparse por los datos integridad. Por supuesto, mantener la compatibilidad con Mac OS clásico era una limitación deseable en Mac OS X 10.0, pero ya no lo es en Mac OS X 10.7.


1
Gran enlace; eso cubre muchas cosas importantes. La falta de compatibilidad con archivos escasos es bastante loca. Linux ext2 hizo archivos dispersos incluso con una asignación simple basada en mapa de bits de bloque, como los usos de HFS +. Sin embargo, creo que hace un gran negocio sobre el almacenamiento de metadatos en big-endian. La bswapinstrucción x86 es muy rápida. Hace que el código sea más grande y más feo, pero mantener la compatibilidad en el disco es un gran problema. Linux XFS todavía almacena todos los metadatos big-endian (excepto native-endian en el diario), debido a su origen en SGI en las CPU MIPS. No es una situación ideal, pero XFS no se detiene.
Peter Cordes

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. Partiendo de ese trasfondo, me ha sorprendido que en un sistema operativo bastante moderno como OSX, el sistema de archivos tenga peculiaridades como la forma en que los nombres de los archivos están "mezclados".

Entiendo que los problemas de Linus con HFS + provienen del mismo punto: por lo que descubrí al investigar el problema, HFS + almacena los nombres de los archivos que usan Unicode, pero cuando un archivo usa caracteres "extendidos" o NO ASCII (como á, é, í, ó, ú, ñ (en español o cosas como la ü 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 un problema real cuando El archivo se ha creado y consumido en OSX, pero cuando comparte información con los usuarios de otros sistemas operativos, el hecho de que el nombre del archivo cambie, genera todo tipo de comportamientos extraños ...

Caso en cuestión: He estado rastreando mis "artefactos" de trabajo (archivos, documentos, etc.) en Subversion durante los últimos 8 años. Cuando me mudé a Mac, obtuve el cliente SVN para Mac, y después de hacer un Checkout de mis directorios relevantes, descubrí que todos los archivos que tienen acentos parecen faltar, y un nuevo archivo con el mismo nombre aparece como no versionado. Profundizando en ello, el problema es que el archivo EN el sistema de archivos está codificado en manzana, mientras que los datos en el repositorio usan otra codificación Unicode (perfectamente válida y legítima) ...

Esto, creo, es una gran "destrucción" de mis datos. Apple entiende ambos formatos de codificación de nombre de archivo (el acceso a un recurso compartido en Windows o el uso de una memoria USB de Windows muestra los nombres de archivo adecuados, etc.) pero en el momento de la creación del archivo, se decidió "sabe mejor" y simplemente cambió el nombre de los archivos. ..

Una vez más, no es algo que la mayoría de los usuarios notarán, ¡hasta que hagan una copia de un archivo, o lo renombren, lo vuelvan a colocar donde estaba el original y terminen con dos archivos que aparentemente son iguales!)


1
Este es solo un punto, y el problema real es que diferentes sistemas operativos simplemente normalizan las cadenas de diferentes maneras, y las aplicaciones multiplataforma no se ocupan de eso. No normalizar los nombres probablemente sería peor (podría tener dos archivos diferentes con nombres que se normalicen en la misma cadena, en OS X).
Blaisorblade

4

John Siracusa y Dan Benjamin discuten algunas desventajas de HFS + en Hypercritical # 56 .

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


9
¿Hay alguna forma de proporcionar un resumen de su discusión en su respuesta? La transmisión de audio es (en este momento en nuestra tecnología actual) no se puede buscar y es muy larga. Sin mencionar que está en otro sitio, por lo que es susceptible a la pudrición de enlaces. Esta sería una respuesta mucho mejor si contuviera detalles específicos sobre su discusión.
Ian C.

1
La conversación del sistema de archivos comienza a los 23 minutos.
neoneye

1
La mayor parte de la información disponible en el podcast también se puede encontrar en un artículo de Ars Technica de John Siracusa (uno de los dos hombres en el podcast).
TML
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.