Checking the health of your SSD from GNU/Linux

As you already know, SSDs degrade over time, as its memory cells support a limited amount of writes (a sacrifice that many people, including myself, find worthy in exchange to get rid of those slow and noisy mechanical disks).

This morning, while talking to a colleague, an interesting question was raised: how do we know when our SSD is near to day of its defunction?

Expensive, enterprise-grade SSD cards, like the ones from TMS, come with monitoring tools and a nice entry in “/proc” that can be easily checked by a script. But I had no idea if there’s some similar for consumer SSDs.

Turned out it was quite easy. Most models provide health info via the S.M.A.R.T. feature, so you can obtain it with smartctl (on Fedora, this utility came into the package smartmontools:

[slopez@slp-work ~]$ sudo smartctl -a /dev/sda
(...)
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
9 Power_On_Hours 0x0032 099 099 --- Old_age Always - 23
12 Power_Cycle_Count 0x0032 099 099 --- Old_age Always - 34
177 Wear_Leveling_Count 0x0013 099 099 --- Pre-fail Always - 1
178 Used_Rsvd_Blk_Cnt_Chip 0x0013 077 077 --- Pre-fail Always - 458
190 Airflow_Temperature_Cel 0x0022 067 051 --- Old_age Always - 33
235 Unknown_Attribute 0x0012 099 099 --- Old_age Always - 10
(...)

The most relevant attribute while checking the health of our SSD, is Wear Leveling Count (more info on Wear_leveling on Wikipedia). But don’t get fooled by its name, it’s not really a count, but an indicator of how healthy are the cells in your disk, where 100 is the best, and 0 the worst.

When this value falls below 20, you should start considering backing up your data and buying a new disk.

Read More

Java, Google y Oracle, un triángulo amoroso conflictivo

Piense por un momento en el número de aplicaciones Java que emplea usted con frecuencia. Ahora, repita el ejercicio con un usuario doméstico convencional. Lo más habitual será que responda “una” o “ninguna” en ambos contextos. Y es que, en la práctica, la presencia de aplicaciones Java en PCs de escritorio se limita en gran medida a un puñado de applets empleados en ciertos sitios web para superar algunas de las tradicionales limitaciones que imponían los lenguajes ejecutados en el navegador. Pero, a medida que estas limitaciones se reducen, lo hace también el ya de por sí estrecho marco funcional de dichos applets.

En el frente de los servicios web, la cosa no pinta mucho mejor para Java. La nueva generación de servidores de aplicaciones incumplieron la promesa de ponerse a dieta, y siguen siendo monstruos pesados, complejos y poco eficientes. Los frameworks más populares, sufren de los mismos síntomas. En conjunto, esto ha provocado que la mayor parte de empresas jóvenes del sector de las TI hayan evitado el uso de estas tecnologías (aunque no de la JVM, que gracias a lenguajes como ScalaGroovyClojurejRuby, parece estar viviendo una segunda juventud), al menos en el corazón de su negocio.

Y no es que no sea posible escribir aplicaciones eficientes en Java. OpenDJ es, probablemente, el servidor LDAP más rápido del planeta. A su vez, la evolución de los garbage collectors concurrentes, ha puesto fin (si el programador toma las precauciones apropiadas) a la temida recolección “stop-the-world”, lo que posibilita el uso de la JVM en entornos donde es crítico que los servicios resuelvan las peticiones en un tiempo limitado. El problema es, en mi opinión, el abandono total de cualquier visión pragmática en pos de la aplicación estricta, y casi enfermiza, de formalismos y patrones. Lo cual se traduce en que las tareas más sencillas se hayan convertido en el recorrido reiterativo de stack traces kilométricas.

Por fortuna para Java (y por desgracia para muchos programadores), le queda un reducto donde parece estar a salvo del embite del resto de lenguajes: el entorno financiero. Gracias al empuje que, en su momento, le dieron Sun, IBM y Oracle, este lenguaje se ha convertido (aunque algunos rechacen reconocerlo por las connotaciones negativas que conlleva) en el nuevo COBOL. Y no es de extrañar, ya que son precisamente estas empresas las más proclives a sacrificar rendimiento y flexibilidad, a cambio de la promesa de un entorno estable y predecible (que Java y sus frameworks sean realmente capaces de sostener esta promesa es un asunto bastante discutible, pero ese es otro tema).

Y entonces, llegó Android

Las circunstancias expuestas arriba hacen que, a pesar de ser un lenguaje que suele estar presente en los entorno académicos, Java perdiera el sex appeal entre los nuevos programadores. Pero entonces llegó Android, para el cual Google decidió que se usaría Java con una implementación de la API y la JVM desarrolladas por ellos mismos. Y con Android, la fiebre de las aplicaciones móviles se extendió a un nuevo terreno,siendo Java el vehículo preferente para recorrerlo. Y así, este lenguaje que parecía languidecer por momentos, obtuvo el balón de oxígeno que tanto necesitaba.

Pero a pesar del tremendo favor que Google le estaba haciendo a Oracle al empujar a las nuevas generaciones de ingenieros para que mantuvieran el interés por Java, los chicos de Larry Ellison decidieron denunciar al rey de los buscadores por el uso“inapropiado” de “su” lenguaje. Obviamente, la intención del gigante rojo no era otra que monetizar la inversión que hizo en Sun, y que parecía no encontrar forma de rentabilizar. Y como innovar no parece ser lo suyo, decidió probar por la vía legal. Que los abogados son más baratos que los buenos ingenieros. O por lo menos, visten mejor.

El caso es que así fue, y no puedo decir que me sorprenda. Oracle a los mandos de un negocio distinto de el de las bases de datos, es como un elefante en la cabina de un Boeing 747. Ni siquiera él mismo sabe qué hace allí, y lo más probable es que termine estrellándolo.

Read More

El paro y la reforma laboral, análisis de un ciudadano

Renuncia de responsabilidad

En primer lugar, quiero dejar claro que no soy un experto en economía. Simplemente soy un ciudadano más con cierta curiosidad, que lleva varios días recabando información sobre este tema. Mi intención con esta entrada es consolidar mi opinión, hacerla pública y aprender, si alguien tiene a bien corregirme (os invito a todos los que tengáis algo que aportar a dejar vuestros comentarios).

La evolución de la tasa de desempleo en España

Como muchos habréis visto en repetidas ocasiones, circulan por Internet y otros medios de comunicación un sinfín de gráficas que afirman representar la tasa de desempleo en España. Lamentablemente, muchas de ellas tienen un carácter claramente tendencioso, con la intención de culpar a unos y vanagloriar a otros.

En este artículo, voy a emplear la siguiente gráfica (extraída de este blog:http://oroel.blogspot.com/2011/04/la-encuesta-de-poblacion-activa.html) en la que las proporciones son lineales y se remonta hasta 1976:

En ella podemos apreciar la siguiente evolución:

  • La gráfica comienza en un ciclo ascendente causado por la Crisis del Petróleo de 1973 y el complejo clima político de los últimos días del régimen de Franco y el proceso de transición. [1]
  • En 1985, tres años tras la entrada por primera vez del PSOE en el gobierno, se detiene la destrucción de empleo e incluso se reduce la tasa de paro hasta situarse ligeramente por encima del 15% entre 1989 y 1990.
  • Entre 1991 y 1992 se produce un ligero incremento del paro, hasta 1993 en que la crisis mundial de principios de los 90 irrumpe con fuerza en España. En este punto comienza un ciclo de destrucción de empleo que duraría hasta mediados de 1994, cuando el paro alcanzó el 24.1% [2].
  • A finales de 1994 comienza un nuevo ciclo de creación de empleo. Dicho ciclo comienza con el PSOE de Felipe González todavía en el poder (aunque algunos atribuyen erróneamente el mérito a su sucesor) y mantiene un ritmo de creación de empleo constante en los primeros años del gobierno de Jose María Aznar (PP), a excepción un ligero estancamiento en 1999.
  • Posteriormente, a finales de 2000 y principios de 2001, en la segunda legislatura del gobierno del PP, la creación de empleo se estanca alrededor del 10% y el paro sufre un ligero repunte. Esta circunstancia puede estar ligada a la conocida como “Crisis de las Puntocom”, aunque no he encontrado datos objetivos que avalen esta afirmación.
  • Entre 2004 y 2008, con el PSOE de José Luis Rodríguez Zapatero en el poder, la tasa de desempleo se mantiene razonablemente estable (el descenso que se aprecia en la gráfica está ligado a un cambio en el sistema de valoración de la E.P.A.)a pesar de la inyección de población activa que supuso la legación masiva de inmigrantes en situación irregular.
  • En 2008 estalla la crisis de la burbuja inmobiliaria y comienza un ciclo agudo de destrucción de empleo que lo dispara hasta la tasa actual del 20%.

Ideas que se pueden extraer del análisis de la gráfica

El primer hecho que me llama poderosamente la atención, es la tremenda inestabilidad del mercado laboral español, capaz tanto de destruir como de crear empleo en plazos extremadamente cortos. Esto es especialmente significativo cuando se compara con el grado de fluctuación de la tasa de desempleo con la otros países de Europa. En los últimos 10 años, la variación (valor en el punto máximo menos valor en el punto mínimo) en España ha sido de 11.8 puntos, mientras que en Portugal [3], Italia [4] y Francia [5] ha sido de 3.5, 2.4 y 2 puntos respectivamente.

Adicionalmente, la gráfica evidencia un claro efecto rebote entre el ciclo de creación de empleo que comenzó en 1994 y el actual de destrucción, poniendo de manifiesto que las estrategias de crecimiento promulgadas por el gobierno de Felipe González primero, y el de José María Aznar después, aunque fueron capaces de generar empleo rápido, crearon puestos de trabajo de mala calidad y en sectores poco competitivos.

Según la FEDEA (Fundación de Estudios de Economía Aplicada) [6] la inestabilidad de este modelo de crecimiento envenenado se nutre fundamentalmente de la dualidad del mercado laboral, repartido entre contratos temporales altamente precarios y contratos indefinidos ligeramente sobreprotegidos. Asimismo, también señala la falta de flexibilidad del sistema de negociación colectiva.

La reforma laboral del Partido Popular

Hace escasos días, el Partido Popular, esta vez con Mariano Rajoy al frente, promulgó una reforma laboral destinada a atajar la destrucción de empleo. Lamentablemente,dicha reforma no sólo no elimina el problema de la temporalidad, sino que lo empeora introduciendo un contrato de formación hasta los 30 años de edad y un contrato indefinido con periodo de prueba de un año (comportándose como un contrato temporal, a efectos prácticos).

Asimismo, a la hora de incrementar la flexibilidad del mercado laboral, en lugar de buscar un equilibrio de fuerzas razonable entre trabajadores y empresarios, otorga de golpe a estos últimos la potestad de variar las condiciones laborales de forma prácticamente unilateral.

Por otra parte, a pesar de que todos los implicados coinciden en señalar al empleo de baja calidad como la causa fundamental de la inestabilidad del modelo español, el plan del PP no contempla un incremento sustancial de las inversiones en I+D+i, ni una mejora efectiva del sistema educativo que incremente la cualificación de los trabajadores. Tampoco contiene ninguna iniciativa pública para el fortalecimiento del tejido industrial de carácter nacional.

A título personal, hay dos cosas que me llaman poderosamente la atención al respecto:

  • Que esta reforma, en su conjunto, esté claramente inspirada en reformas similares ejecutadas en otros países europeos, a pesar de que los datos señalan que el caso de España es único en la UE, y debería tratarse de forma particular.
  • El hecho de que el PP evite resolver el problema de la temporalidad y la calidad del empleo, a pesar de haber sido ambos reiteradamente señalados como principales causantes de la inestabilidad del marcado laboral. Esto me hace sospechar que su intención real no es otra que intentar reproducir el ciclo de crecimiento rápido que tuvo lugar entre 1994 y 2001, aún siendo sabedores de las consecuencias que esta estrategia ha tenido (y está teniendo). Espero equivocarme, pero todo apunta a que quieren volver a construir un gigante con pues de barro, con la esperanza de que se desplome cuando esté otro al mando.

Referencias

[1] http://es.wikipedia.org/wiki/Crisis_del_petr%C3%B3leo_de_1973
[2] http://es.wikipedia.org/wiki/Crisis_del_petr%C3%B3leo_de_1979
[3] http://www.oecd-ilibrary.org/economics/country-statistical-profile-portugal_20752288-table-prt
[4] http://www.oecd-ilibrary.org/economics/country-statistical-profile-italy_20752288-table-ita
[5] http://www.oecd-ilibrary.org/economics/country-statistical-profile-france_20752288-table-fra
[6] http://www.crisis09.es/propuesta/?page_id=37

Read More

Adobe Flash: The misunderstood ugly guy

Almost everyone hates Flash, and the discontinuation of it’s mobile version was seen by many as a triumph.

Being a GNU/Linux user myself, I also suffered all those crappy versions, late releases and crazy development cycles. But, looking back and trying to be fair, I must acknowledge that the availability of a Flash player for the major operating systems has lowered the barrier for multiplatform development for many people, specially for independent companies. And I’m not talking only about embedded videos on websites, but also videogames (like Machinarium or VVVVVV) and applications. In some sense, Flash was more successful than Java at building bridges between platforms.

That said, the failure of Flash on mobile platforms is not surprising at all. Pride seems to be the favorite sin for Adobe. They were barely able to produce decent quality versions for non-mobile platforms, so it was pretty clear their development work force wasn’t strong enough to provide properly optimized versions for the more complex Android ecosystem.

Adobe rejected the option of freeing its Flash Player, while keeping Adobe Flash (the content creator) as a commercial product. Apparently, they feared publishing the source code of its player would make easier for its competitors to provide alternative editors. But competition is not a bad thing, as it usually enriches the ecosystem and increases the popularity of a product. And opening the player would have extended Flash to newer platforms, improved the quality of non-Windows versions, and reduced total development cost, giving them more chances to success on mobile platforms. Perhaps they would even won the favor of some other companies (namely Google), which would in turn embed support for Flash on their own products by themselves.

Adobe lost their big chance. Not even them understood the truly potential of their own product.

Read More

How Intel/AMD (inadvertently) fixed GNU Hurd

Last Friday, on Hurd’s IRC channel at freenode, we’ve accidentally noticed some machines were able to run certain operations on Hurd as KVM guest up to 10x faster than others. As antrik correctly guessed, this is the effect of Intel’s Extended Page Tables, which allow the guest operating system to deal with it’s own page faults. I suppose AMD’s Rapid Virtualization Indexing could have a similar effect, but I don’t have the hardware to be able to test it (please write to the mailing lists if you’ve been able to check it).

Since most people (including myself) are running Hurd in a virtualized environment, having the ability of taking advantage of this circumstance by moving to hardware with this technology supposes a great improvement, heavily reducing compilation times and increasing the interactivity of the entire system.

Let’s see an small example of the difference between running with and without EPT.

Running without EPT (modprove kvm-intel ept=0):
root@debian:~# dd if=/dev/zero of=/dev/null bs=256k count=1000
1000+0 records in
1000+0 records out
262144000 bytes (262 MB) copied, 2.08 s, 126 MB/s

And with EPT:
root@debian:~# dd if=/dev/zero of=/dev/null bs=256k count=1000
1000+0 records in
1000+0 records out
262144000 bytes (262 MB) copied, 0.23 s, 1.1 GB/s

I think there will be interesting times for GNU Hurd.

Read More

Sometimes, swap space still matters

Most modern, general purpose Operating Systems (OS), come with a full-fledged Virtual Memory (VM) system that generates the illusion of having more memory than the real amount installed in the machine. Whether this virtual memory is backed by real RAM, disk swap or it just isn’t backed by any physical device, is something up to the OS.
This way, you can reserve (though the man page of malloc() says allocate, when you know how it works behind the scenes, reserve sounds better) 2 GB of memory in a machine with only 1GB and no swap. Of course, if you try to use that amount memory within your application, the OS will have a hard time trying to make space for it to run (probably reaping file sytem caches and buffers), and at some point it will take the decision of either killing the process (like the OOM Killer of Linux) or refusing to provide more pages to the space of that process, causing this one to die with a segmentation fault.This ability of allowing the processes to reserve more memory than the amount physically available, is possible thanks to on-demand paging. This means that physical resources (in this case, memory pages) are not consumed by a process until it really access them:

#define SIZE 1024*1024*100

int main()
{
int i;
char *buf;

buf = (char *) malloc(SIZE);

/* At this point, memory usage on the OS shouldn't have changed considerably */

for (i=0; i<SIZE; ++i) {
buf[i] = 'A';
}

/* Now, free memory in the OS should have decreased by 100 MB */

free(buf);
}

Many applications take advantage of this feature, and reserve more memory than they really use in all their lifecycle (if this is a proper behavior or not, is something beyond the scope of this article). You can check this in your own UNIX OS by comparing the columns VIRT and RSS (or RES) of the top utility.

So, how much memory can be reserved?

This is something that depends entirely on the OS you’re running. But most of them calculate a “safe” value determined by the amount of RAM and the size of the disk swap. This is the case for Solaris, which goes even further by strictly limiting the amount of memory to be reserved to the sum of the RAM and the swap minus 1/8 of the first one.

What could happen if you configure a low amount of swap space? (A real world example and the motivation of this article)

This morning, in one of our OpenSolaris servers, we started to receive messages like this one: “WARNING: Sorry, no swap space to grow stack for pid …” In vmstat, theswap column (a misleading name, since it’s the amount of virtual memory available to be reserved, and not something strictly related to physical swap space) showed pretty low numbers (under 50MB) while the free column was telling us that there were over 14 GB of physical RAM available. How can this be possible?

This machine has 32 GB of RAM and only 512 MB of swap (the default size in OpenSolaris, my mistake). This means that the total amount of virtual memory available to be reserved is something around 30 GB. It provides CIFS service to the network with SAMBA, thus there’re lots of “smbd” processes running on it, and each process usually has a VIRT size of 40 MB, and a RSS of 20 MB. With 1000 processes, the required amount of physical memory would be a little under 20 GB (it fits in RAM), but the amount of virtual memory is something near 40 GB.

This way, when our system reached the limit of virtual memory (over 30GB), it still had more than 10 GB of real RAM available, but the OS refused to allow more reservations. And since there’s still plenty of free pages, the kernel doesn’t try to rebalance the size of it’s buffers, leaving you with and exhausted system with lots of free memory.

So, keep in mind: Even with lots of RAM installed in your server, sometimes, swap space still matters.

Read More

How device size affects disk performance in Linux (II)

I’ve just noticed that in a virtualized environment, where roundtrips are more expensive, read speed differences between a page-aligned partition and a non page-aligned one are even more noticeable:

Non-aligned partition (size in sectors: (41929649-63)+1=41929587):

none:~# fdisk -l -u /dev/sdb

Disk /dev/sdb: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 x 512 = 512 bytes
Disk identifier: 0x93dbf2be

Device Boot Start End Blocks Id System
/dev/sdb1 63 41929649 20964793+ 83 Linux

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=0
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 3.80593 s, 27.6 MB/s

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 3.82304 s, 27.4 MB/s

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=200
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 3.83713 s, 27.3 MB/s

Page-aligned partition (size in sectors: (41929654-63)+1=41929592) :

none:~# fdisk -l -u /dev/sdb

Disk /dev/sdb: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 x 512 = 512 bytes
Disk identifier: 0x93dbf2be

Device Boot Start End Blocks Id System
/dev/sdb1 63 41929654 20964796 83 Linux

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=0
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.618494 s, 170 MB/s

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.582423 s, 180 MB/s

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=200
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.589081 s, 178 MB/s

NOTE: In both tests, the data is cached in the host (so there is no real I/O to disks but traffic through virtualization pipes), but clean in the guest.

Read More

How device size affects disk performance in Linux

While running some tests in a client’s environment, we’ve noticed reading from a partition of a multipath device was considerably slower than reading from its parent node:

[root@none]# dd if=mpath4 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 8.92711 seconds, 120 MB/s

[root@none]# dd if=mpath4p1 of=/dev/null bs=1M count=1024 skip=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 17.5965 seconds, 61.0 MB/s

We asked to client support of a well-known GNU+Linux vendor, and they indicated that this behavior was “expected”, since this kind of partitions were created by stacking adm-linear device over the original multipath node. I wasn’t satisfied by this answer, since AFAIK dm-linear only did a simple transposition of the original request over an specified offset (the beginning of the partition), so I decided to investigate a bit further on my own.

The first thing I’ve noticed, was that changing size of the dm-linear device affected the performance of the tests:

[root@none]# echo "0 1870000 linear 8:96 63" | dmsetup create test
[root@none]# dd if=/dev/mapper/test of=/dev/null bs=1M count=100 skip=600
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.906487 seconds, 116 MB/s

[root@none]# dmsetup remove test
[root@none]# echo "0 1870001 linear 8:96 63" | dmsetup create test
[root@none]# dd if=/dev/mapper/test of=/dev/null bs=1M count=100 skip=700
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 1.47716 seconds, 71.0 MB/s

This was something, but then I needed to find the reason of how a simple change in the device size could impact the performance this way. Playing around with kgdb (what a nice tool!), I’ve reached to this piece of code from Linux (drivers/md/dm.c):

static int __split_bio(struct mapped_device md, struct bio bio)
{
struct clone_info ci;
int error = 0;

ci.map = dm_get_table(md);
if (unlikely(!ci.map))
return -EIO;

ci.md = md;
ci.bio = bio;
ci.io = alloc_io(md);
ci.io->error = 0;
atomic_set(&ci.io->io_count, 1);
ci.io->bio = bio;
ci.io->md = md;
ci.sector = bio->bi_sector;
ci.sector_count = bio_sectors(bio);
ci.idx = bio->bi_idx;

start_io_acct(ci.io);
while (ci.sector_count && !error)
error = __clone_and_map(&ci);

dec_pending(ci.io, error);
dm_table_put(ci.map);

return 0;
}

In the debugging session, I’ve noticed that ci.sector_count takes the value ‘1’ for the device with worst performance, while other devices with different sizes and better read speeds could take values in a range from ‘2’ to ‘8’ (being the latter the case with best performance). So, indeed, the size of a device affects how is accessed, and this implies a noticeably difference in performance. But, still, it wasn’t clear for me where is the root of this behavior, so I decided to dig a bit deeper. That took me to this function (fs/block_dev.c):

void bd_set_size(struct block_device bdev, loff_t size)
{
unsigned bsize = bdev_logical_block_size(bdev);

bdev->bd_inode->i_size = size;
while (bsize < PAGE_CACHE_SIZE) {
if (size & bsize)
break;
bsize <<= 1;
}
bdev->bd_block_size = bsize;
bdev->bd_inode->i_blkbits = blksize_bits(bsize);
}

This function searches for the greatest power of 2 which is divisor of the device size in the range of 512 (sector size) to 4096 (the value for PAGE_CACHE_SIZE in x86), and sets it as the internal block size. Further direct requests to the device will be internally divided in chunks of this size, so devices with sizes that are multiple of 4096 will perform better than the ones which are multiple of 2048, 1024 or 512 (the worst case, which every device conforms as its the size of each sector). This is specially important in scenarios in which devices are directly accessed by the application, such as in Oracle’s ASM configurations.

TL;DR: Linux chooses the internal block size that will be used to fulfill page requests by searching the greatest power of 2 which is divisor of the device size in a range from 512 to 4096 (in x86), so creating your partitions with a size which is multiple of 4096 will help to obtain better performance in I/O disk operations.

Read More

DRM y Software Privativo van de la mano

Navegando por reddit, me he encontrado con esta entrada en la que un usuario se queja de que no puede reproducir un Blue-Ray legítimamente adquirido, ya que está utilizando como salida de vídeo una TV conectada al puerto HDMI de su portátil (un Macbook Pro).

En dicha entrada se comenta cómo los fabricantes se perjudican a sí mismos con este tipo de prácticas. Ciertamente es un aspecto a destacar, pero también es importante tener en cuenta que dichas prácticas no serían posibles sin que existiese cierto Software Privativo que haga efectivas las limitaciones artificiales impuestas por los fabricantes. Y donde hoy es impedir que se reproduzca un contenido si se visualiza en una TV sin HDCP, mañana podría ser cualquier otra prohibición igualmente ridícula y arbitraria.

Y es que este es uno de los principales motivos por los que Richard M. Stallman inició el proyecto GNU hace 25 años: impedir que los fabricantes tuvieran la capacidad de decidir sobre lo que el usuario puede o no hacer con su computadora. El Software Libre, como su propio nombre indica (al menos en su denominación castellana, más precisa que la anglosajona), trata sobre la libertad, y no sobre la gratuitidad, matización que con frecuencia se suele pasar por alto.

Si en atención a nuestra comodidad entramos en el jardín vallado que nos presentan y damos por buenas este tipo de prácticas (y entre ellas podemos incluir también modelos de distribución de software como el AppStore), le estamos dando vía libre a los fabricantes para que tomen el control de nuestros dipositivos y decidan por nosotros lo que podemos hacer con ellos. Y los peligros que esto entraña en una sociedad donde las TI están presentes a todos los niveles (y cada días más), son impredecibles.

Read More

Webs de administración y puertos redirigidos

Si trabajas administrando sistemas, es posible que te hayas encontrado en la tesitura de tener que acceder a la consola de administración de algún dispositivo a través de un túnel SSH, redirigiendo algún puerto de la máquina de destino a otro local. Al hacer esto, puedes encontrarte con la circunstancia de que la aplicación a la que estás accediendo tiene referencias estáticas a su IP real, lo cual provoca que no puedas acceder correctamente a ella.

Si este es tu caso, y estás utilizando GNU/Linux, puedes hacer uso de iptables para salvar el escollo. Por ejemplo con

iptables -t nat -A OUTPUT -p tcp --dport 9000 -j DNAT --to 127.0.0.1:9000

estaríamos redigiriendo todo el tráfico saliente hacia el puerto 9000, al mismo puerto en nuestra máquina local.

Read More