inotify

El otro día en un thread sobre inotify se leia una cosa interesante. El jugo de inotify es monitorizar cosas sobre inodos. Entre otras cosas, puedes decirle a inotify, con IN_DELETE_SELF, que te avise de cuando un archivo va a ser borrado

Y aquí venía el problema curioso. Inotify vigila a los inodos, y como buen sistema unix, en linux la ruta "/foobar/archivo" no es mas que un "enlace" a un inodo. Puedes borrar ese enlace a ese inodo para borrar el archivo, puedes hacer que apunte a otro inodo, pero el inodo antiguo seguirá ahí y puedes seguir escribiendolo o leyendolo (razón por la cual en unix es posible sobreescribir un archivo mientras está abierto, ej: al actualizar paquetes)

Y ahí está el problema: Si quieres "espiar" con inotify y con IN_DELETE_SELF el momento de borrado de un archivo, te encontrarás con que despues de hacer un "rm" inotify no notifica nada porque el inodo aun existe. El problema es que en unix no puedes monitorizar el borrado de un archivo monitorizando inodos (y por tanto, con inotify) - unix no funciona asi. Asi que como bien dijo linus, la propia existencia de IN_DELETE_SELF es estúpida. No es un defecto de unix ni de inotify: Es una consecuencia del diseño de unix, asi que como dice linus en el mensaje, si quieres monitorizar el borrado de un archivo no tendras mas remedio que monitorizar al directorio. Aunque parece absurdo a primera vista (al menos a mis ojos), esa es la manera "correcta" de hacerlo en unix. Me parecia algo curioso para comentar.

¡por fin! escritura para NTFS

Anton Altaparmakov es el PUTO AMO. En el último anuncio del -mm ha anunciado que ya tiene soporte COMPLETO para escritura en NFTS (le falta el soporte para crear y borrar archivos, algunos problemas con archivos fragmentados) pero supongo que si ha llegado hasta este punto, es cuestión de tiempo...

Y digo PUTO AMO porque hay que tener huevos, muchos huevos, para implementar un sistema de archivos complejo como lo es NTFS sin NADA DE DOCUMENTACION de parte del autor. Como referencia, el soporte de UFS para sistemas de archivos de freebsd, que tiene el codigo 100% abierto y es mucho mas sencillo que NTFS y muy parecido en diseño a ext2, solo tiene soporte de lectura, y a saber si tendrá el de escritura algun dia. Lo dicho, el puto amo.

solaris vs freebsd vs linux

De eso va mas o menos interesante artículo que compara los kernels de solaris, freebsd y linux desde un punto de vista constructivo (que no es poco). Algunas cosas son curiosas

Solaris has support for a "fixed priority" class, a "system class" for system threads (such as page-out threads), an "interactive" class used for threads running in a windowing environment under control of the X server

En Linux, Ingo Molnar propuso cosas parecidas (añadir algo que permitira marcar a las X & friends como "interactivos" para poder tratarlos de manera especial, o poner las X a prioridad -10 para olvidarse de los problemas). Linus lo rechazó frontalmente: In short, you're taking a very NT'ish approach - make certain programs run in the "foreground", and give them a static boost because they are magically more important. And you're ignoring the fact that the heuristics we have now are clearly fundamentally broken in certain circumstances

Esta es la misma la razón por la que de momento Linux no incluye (de momento) la capacidad de cambiar de tipo de scheduler "en vivo" como hacen solaris y otros unix "serios" (que haberlos haylos): En linux se cree que si tienes que recurrir a eso es porque el scheduler principal tiene un bug, y que lo mas logico es arreglar ese bug, no "workaroundear" el problema añadiendo complejidad. Supongo que es ese tipo de actitud la que hace que prefiera linux a los demás.


Linux divides machine-dependent layers from machine-independent layers at a much higher level in the software. On Solaris and FreeBSD, much of the code dealing with, for instance, page fault handling is machine-independent. On Linux, the code to handle page faults is pretty much machine-dependent from the beginning of the fault handling. A consequence of this is that Linux can handle much of the paging code more quickly because there is less data abstraction (layering) in the code. However, the cost is that a change in the underlying hardware or model requires more changes to the code

Igual que esta. Linux tendrá mas codigo dependiente de máquina, pero sacrificar el rendimiento de algo tan importante y tan utilizado por ahorrar esfuerzos a la hora de programar es algo que no va con el "espiritu linux"


Y la mejor de todas: Solaris, FreeBSD, and Linux are obviously benefiting from each other. With Solaris going open source, I expect this to continue at a faster rate.