Linux & Unix

In this era of multi-core, multi-gigaherz CPUs, traditional platter-based hard disks remain the “weak link” of modern machines. And they are here to stay: while SSDs are rapidly evolving and their prices are dropping, the cost per GB of storage space offered by HDDs is simply unmatched by their flash brothers.

The work of the I/O scheduler, a key component of every operating system, is precisely to extract as much juice as possible from these aging HDDs. Linux has not only one or two, but no less then four I/O schedulers at your disposition. Here is a brief explanation of these schedulers (taken from this Red Hat article):

• the Anticipatory scheduler introduces a controlled delay before dispatching the I/O to attempt to aggregate and/or re-order requests improving locality and reducing disk seek operations. This algorithm is intended to optimize systems with small or slow disk subsystems;
• the Completely Fair Queuing (CFQ) scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests;
• the Deadline scheduler uses a deadline algorithm to minimize I/O latency for a given I/O request;
• the Noop scheduler is a simple FIFO queue, and it assumes performance of the I/O has been or will be optimized at the block device.

"Write once, run anywhere" is the "holy grail" and hidden dream of any developer that has to support multiple platforms and operating systems.

While many programming languages and associated virtual machines attempt to solve this problem, Java + JVM is one of the best know (and best performing) multi-platform software stack. It evolved from a sub-performing, very slow interpreter-based solution to a fast JIT-based, reliable and secure system.

As other multi-platform languages, Java first compile itself in an intermediate state know as "bytecode". This bytecode is then executed by the real machine compiler, the Java Virtual Machine (JVM in short). So, it become clear that a good JVM is crucial to obtain high performances from your Java code.

As you known, BTRFS is the new, full-featured filesystem being developed for Linux. While BTRFS  remain marked as “experimental”, it catalyze much attention in the filesystem community due to its impressive feature lists, relentless development and performance promises.

Speaking about performances, however, it seems that BTRFS has some significant problems, especially with database files and virtual machine images. With the latter, BTRFS speed is so low [1] that the official KVM tuning guide advise against using it [2].

In common scenarios, storage subsystem speed represents a significant performance bottleneck: classical electromechanical disks are very good at areal density and sequential read/write speed, but they are terribly slow at random and/or mixed read/write operations. Moreover, being  electromechanical devices, normal hard-disks are quite prone to failures and malfunctions.

While SSD (and even more expensive RAM-DRIVE) significantly addresses this problem, the reality is that platter-based disks are currently the dominant storage media, and this situation will hardly change in the following 3-5 years.

In order to increase performances and reliability, many servers/workstations/NAS combine, in differnt fashion, multiple disks into single logical drives. This multi-disk-for-a-volume schema is called RAID – Redundant array of independent (or inexpensive) disks. You can read more on the subject here and here.