Linux & Unix

You probably know what LVM is: is Linux's Logical Volume Manager. Its role is to give you a flexible partition scheme for your ever-increasing disk space: while standard partition (MBR or GTP style) are semi-static entries (they can be quite tricky to resize), expanding a LVM based partition is a much nicer experience.

However, while LVM's dynamic nature is a much appreciated feature, in complex situations you can find normal LVM volumes not flexible enough.

NOTE: these information were originally provided in a post I wrote on the Joomla forum

Many CentOS and Joomla users had a bad surprise lately: while Joomla 3.2 happily run on CentOS provided PHP packages (5.3.3), the 3.3 update strongly refuse to run on anything that PHP 5.3.10, citing security issues as the main reason. In my opinion, this is not a wise move - after all, the long-term distribution all apply custom patches and backports to their PHP version and, in this specific case, CentOS packages provide absolutely comparable security to the target 5.3.10 PHP version.

Anyway, we can do very little to change this situation: Joomla developer stated that the will not support older PHP version. So, how can we use Joomla on our beloved CentOS 6.x installations? While custom-patching Joomla's version-check functions can be tempting, this is not the best thing to do: any custom patching increase the risk of future problems, especially when updating your Joomla installation. On the other side, simply using a more up-to-date repository featuring PHP 5.4+ can not be practical: maybe you have other sites on hosted on your server, and (correctly) you don't want to introduce any possible problems for this sites, or you simply want to stick with default repositories.

Fortunately, the solution exists: say hello to "Software collections" or SCL in short.

File compression is an old trick: one of the first (if not the first) program capable of compressing files was “SQ”, in the early 1980s, but the first widespread, mass-know compressor probably was ZIP (released in 1989).

In other word, compressing a file to save space is nothing new and, while current TB-sized, low costs disks provide plenty of space, sometime compression is desirable because it not only reduces the space needed to store data, but it can even increase I/O performance due to the lower amount of bits to be written or read to/from the storage subsystem. This is especially true when comparing the ever-increasing CPU speed to the more-or-less stagnant mechanical disk performance (SSDs are another matter, of course).

While compression algorithms and programs varies, basically we can distinguish to main categories: generic lossless compressors and specialized, lossy compressors.

If the last categories include compressors with quite spectacular compression factor, they can typically be used only when you want to preserve the general information as a whole, and you are not interested in a true bit-wise precise representation of the original data. In other word, you can use a lossy compressor for storing an high-resolution photo or a song, but not for storing a compressed executable on your disk (executable need to be perfectly stored, bit per bit) or text log files (we don't want to lose information on text files, right?).

While SSD are increasingly used in both enterprise and consumer machines, classical mechanical-based HDD are here to stay at least 5-10 more years: their sheer size (and accompanying low cost per GB) means that they will remain the primary storage backed inside most computers. For example, even where SSD are used, a classic HDD is used to store big and/or compressed data.

This also means that any improvement in HDD performance should be taken seriously: as they are (by far) the slower component that can be found inside modern servers and PCs, any improvement in I/O speed can have a direct positive effect on the performance of the entire setup.

Understanding this fact, enterprise-class drives and controllers have long ago acquired a capability called TCQ: an hardware-managed I/O queue that,  through carefully and smart requests reordering, can noticeably improve HDD performance under high queue depth (QD) scenarios. Even on the software side each piece was in place, as any UNIX/LINUX variant traditionally has a well written, high performing I/O stack with an additional I/O software queue that contribute to a even faster disk subsystem.