I must admit the 16.04 demo does look very pleasant to work with.

However, bringing in ZFS into Linux reminded me of a fairly recent comparison of ZFS and btrfs that I had to do when building my home NAS.
At that time, few months ago, I’ve arrived (among others) at the following conclusions:

• ZFS on FreeBSD is reliable, though a memory hog;
• on Debian, OpenVault seems to be a good NAS web-management interface;
• on FreeBSD, FreeNAS is good (there is also Nas4Free fork of an older version, but I haven’t looked into it deep enough);
• running ZFS on linux (even as a kernel module) is the least efficient solution, at least partially because kernel’s file caching and ZFS’s ARC cache are two separate entities;
• although btrfs offers features very similar to ZFS, as of few months ago OpenVault did not offer btrfs volumes support from the web-interface.

In the end, I’ve decided to go with FreeNAS, and it seems to work well so far.

But had anything changed in the btrfs vs ZFS on Linux field?

Luckily, in the comments section of the original post Brian Mullan linked to a recent Bachelor degree project titled A performance comparison of ZFS and btrfs on Linux (local copy). Here’s an excerpt from the abstract:

The main conclusions that can be drawn from the analysis of the gathered data is that
Btrfs has improved greatly in recent years and is today showing great throughput whereas
ZFS on Linux is performing considerably worse than Btrfs.

The document is definitely worth looking at – actual results start on page 22, and there are figures for easy comprehension
XFS and ext4 are also added to the comparison, so if you are thinking about changing your FS – the document may help you, too.
The only area where ZFS excelled was database-like load; btrfs and XFS were the leaders in the majority of other tests.
(In fact, somewhat lower btrfs performance for database-like loads seems to be a well-known thing, and can be cured with the nodatacow mount option – see e.g. this nice rant about PostgreSQL on btrfs.)

I do believe that ZFS is still more stable than btrfs, but I’m also still not convinced that ZFS and Linux are a good combination.

This post is not intended to be an in-depth comparison, but should be sufficient to choose one of the three file formats for your purposes. For more format details and history simply follow the links provided. File formats are reviewed roughly in “historical” order.

PNG (Portable Network Graphics) was designed as GIF replacement.

• It is lossless.
• It is suitable for photos.
• PNG is more space-efficient in the case of images with many pixels of the same color, such as diagrams/plots (as compared to PGF and JPEG2000). However, PNG photos are almost always larger than lossless PGF/JPEG2000 photos (real photo example: 9.9 MB in PNG, 7.0 MB in JPEG 2000).
• PNG is fairly fast at (en|de)coding.
• PNG is widely supported by web-browsers, image editors, and other software.
• PNG uses CRCs internally for each data block, so if damage occurs only the damaged block(s) should be lost – theoretically. However, in practice, according to the Just One Bit paper (local copy), PNG is actually much less damage-resilient than JPEG 2000.

JPEG 2000 (JPEG 2000) was designed as JPEG replacement.

• It has both lossless and lossy modes. Lossy mode is “better” (perceptually at the same file size) than JPEG.
• Lossless mode is the smallest of all 3 file formats tested.
• JPEG 2000 is slower at (en|de)coding than PGF and PNG.
• JPEG 2000 has several associated ISO and other standards. Software support for JPEG 2000 is not as good as for PNG, but better than for PGF.
• JPEG 2000 has good bit errors resilience (local copy).

PGF (Progressive Graphics File) was also designed to replace/enhance JPEG.

• PGF uses the same wavelet-based method as JPEG 2000, so it shares a lot of features with JPEG 2000, including support for lossless and lossy modes, with lossy being “better” than JPEG.
• Lossless mode file is marginally larger than the same image in JPEG 2000 (real photo example: 7.0 MB in JPEG 2000, 7.4 MB in PGF).
• It is much faster at (en|de)coding than JPEG 2000 (this is major difference #1 of 2).
• Software support for PGF is not as good as for JPEG 2000 (this is major difference #2 of 2).
• Being under-appreciated, PGF doesn’t seem to have received any error resilience testing, yet. However, one should expect error resilience similar to that of JPEG 2000, because essentially the same compression method is used (albeit with different “parameters”, resulting in a speed/size trade-off/gain). It is not clear if PGF has any resilience features like JPEG 2000.

Fun fact #1 from the links above: best error resilience was observed for bitmap files.
Fun fact #2: after about 1% of data damage none of the compressed formats is able to reliably reproduce the original image.

I would be happy to use PGF for its speed, compression ratio, and features, but lacking software support is detrimental (in a self-reinforcing manner) to widespread adoption of PGF; being quite similar to the more popular (or better promoted) JPEG 2000, I do not know if PGF will gain sufficient traction to get e.g. browser support.

PNG has very good support, but produces noticeably larger files, and exhibits significantly lower error resilience than JPEG 2000.

So as of today my choice is JPEG 2000 (lossless, with resilience features).

I’m sure that you are aware of the fact that floats representation in any programming language is limited by the precision of the internal binary representations. In other words, you can never have an exact float representation – there will always be some precision associated with the float you are working with. The simplest example is the difference in precision between the float and double types in C.

Suppose I have the following code fragment:
[C] if ( result.score >= input->raw_cut_off ) [/C]

Both result.score and input->raw_cut_off are of type float, and can have positive and negative values. When compared with the greater than or equal ( >= ) operator, it is not always that condition is true – for the precision reasons shortly mentioned above.

As I already said, there is no precision specification for equality operators in C. But it is quite simple to “invent” precision specification; e.g. if I wanted to test for equality only, I could write
[C] if ( fabsf( result.score – input->raw_cut_off ) < 0.000001 )[/C] In this example, I'm effectively asking for 6-digit precision for the equality comparison of floating-point values. Note, that if you replace that 0.000001 with the actual precision limit of the floating type you are using, you will be "exactly" comparing floating-point numbers - up to that type's precision, of course .

The first-most example with the >= operator can be rewritten as
[C] if ( result.score > ( input->raw_cut_off – precision) ) [/C]
where precision is exactly what it is named, e.g. precision = 0.000001.

Sources used:

• comment by Randy A. Ynchausti
• scientific programming