Linux & Unix

EXT3 vs EXT4 vs XFS vs BTRFS filesystem comparison on Fedora 18

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 44

As always, we want to check the current state and performance of Linux filesystems. This time is the turn of Fedora 18 x86_64, with kernel version 3.9.4-200.

The benchmarked filesystems are:

  • ext3, the classic Linux filesystem
  • ext4, the latest of the ext-based filesystem and the default choice for many Linux distribution
  • xfs, an high performance filesystem designed with scalability in mind
  • btrfs, the new, actively developed, feature-rich filesystem

Note that this article has a focus on performance. For an in-depth, feature-based comparison, you can see the relative Wikipedia page.

Linux I/O schedulers benchmarked - anticipatory vs CFQ vs deadline vs noop

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 23

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.

OpenJDK vs OracleJVM: a look at Java performance under RedHat 6.3 with SPECjvm2008

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 16

"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.

BTRFS, mount options and virtual machines: an in-depth look

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 13

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].

Linux software RAID 10 layouts performance: near, far and offset benchmark analysis

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 30

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.