Barrapunto

Por empezar, ojo que en Barrapunto cuestionan la paginación de memoria y eso no es lo que se discute en la presentación. Por supuesto que la paginación de memoria y la memoria virtual es una buena idea. Lo que está en discusión es cargar el código ejecutable vía mapeo de memoria y fallos de página.

Respecto al artículo: Los archivos dispersos (sparse files) son fragmentados por definición. Su función es ahorrar espacio en disco, y debemos utilizarlos cuando el espacio, no el rendimiento, es lo que queremos optimizar. Mozilla Firefox o SQLite nunca deberían utilizarlos.

Otra cosa que hay que destacar de la presentación es que habla de la fragmentación en XFS (y probablemente sobre archivos dispersos). Ocurre que XFS no es el sistema de archivos más popular, ni el mejor, ni el que está por defecto en las distribuciones más populares de GNU/Linux. ext4 tiene este lugar por ahora, y resulta que ext4 tiene uno de los mejores asignadores de bloques que hay, y produce menos fragmentación que NTFS en Windows u otros sistemas de archivos en varios Unices.

También quiero destacar que el comportamiento que Mozilla solicita para SQLite, de hacer crecer a los archivos en bloques grandes (p.e. de 10 MB), es lógico y además es lo que hacen otras bases de datos (p.e. InnoDB) cuando los archivos de datos pueden crecer.

Respecto al núcleo de GNU/Linux, si bien creo que la carga de ejecutables por fallo de página no es tan mala idea, sí que es cierto que podrían cargarse bloques mucho más grandes que 128 KB (quizás 8 veces más grandes) con la entrada-salida que tenemos hoy.

Los Page Faults en linux son un problema que los desarrolladores conocen, y si ves los changesets que realizan en cada versión verás que casi todas las versiones del kernel salen con alguna optimización en el manejo de la memoria, paginación, o que buscan la reducción de E/S.

Ejemplo:

• Kernel 3.0: http://kernelnewbies.org/Linux_3.0 [kernelnewbies.org]
  • Cleancache: http://lwn.net/Articles/386090/ [lwn.net]
• Kernel 3.1: http://kernelnewbies.org/Linux_3.1 [kernelnewbies.org]
  • page allocator: fix significant stalls while copying large amounts of data on NUMA machines
  • [no directamente relacionado] Dynamic writeback throttling: https://lwn.net/Articles/405076/ [lwn.net]
• Kernel 3.2: http://kernelnewbies.org/Linux_3.2 [kernelnewbies.org]
  • I/O-less dirty throttling, reduce filesystem writeback from page reclaim: https://lwn.net/Articles/456904/ [lwn.net]

Lo que no sé decirte, es qué tan graves son estas situaciones en otros sistemas operativos (tanto libre como privativos), ya que no sigo sus desarrollos.

Con respecto a tu frase Ocurre que XFS no es el sistema de archivos más popular, ni el mejor, ni el que está por defecto en las distribuciones más populares de GNU/Linux, te agrego que, hoy en día, no existe 'el mejor sistema de archvos', ya que sin ir as lejos, en determinados workloads, XFS es muy superior a ext4, y en otros, donde ext4 solía destacarse, no es tanto el margen usando las últimas versiones del kernel https://lwn.net/Articles/476263/ [lwn.net]
obviamente estos datos no creo que sirvan para un usuario, ni siquiera un usuario avanzado... ¿cuantos tienen un raid0 de 12 discos en su desktop?
Es evidente que el tipo de carga de trabajo al que apunta XFS no es un equipo hogareño promedio... ¿no?

La idea que aumentes 10Mb (o cualquier valor arbitrario) es que tengas bloques importantes contiguos, si vas creciendo de a porciones mas pequeñas el archivo quedará mucho mas fragmentado; y croe que es normal. No creo que por cambiar el algorito de crecer de a n KB a 10.000 * n KB cambie en lo mas minimo el consumo en disco a largo plazo; disiento contigo con tu afirmación de que va a estar creciendo 10 megas cada 5 minutos

Lo de copiar el archivo a uno nuevo, es algo que no estoy en condiciones de evaluar si es correcto o no tu planteo, nunca trabajé con SQLite.