This page contains various MTD-related information which does not fit the FAQ or Documentation categories.

Table of contents

  1. UBIFS compression experiments on ARM platform
  2. UBIFS large block compression tests

UBIFS compression experiments on ARM platform

This section contains the results of our compression experiments on an ARM platform with 256MiB OneNAND flash. Please, bear in mind that the results are specific to our platform and may be different for other platforms. Flash I/O speed, CPU speed, CPU architecture and contents of the test files greatly affect the results. Please, take this into account before extrapolating our test results to your system.

UBIFS supports LZO and zlib compressors and the mkfs.ubifs tool supports favor LZO compression method. We tried to figure out what is the preferred compression type for our system, and the results of our experiments are below.

Compression type Read speed Read speed in percent Image size Image size in percent Write speed Size of full rootfs image Size of full rootfs image in percent
No compression (-x none) 25.81MiB/s 100% 98.2MiB 100% 4.3MiB/s 301.8MiB 100%
LZO (-x lzo) 18.31MiB/s 70.9% 58.1MiB 59.2% 4.0MiB/s 170.3MiB 56.4%
Favor LZO 20% (-x favor_lzo -X 20) 16.72MiB/s 64.8% 56.4MiB 57.4% - 164.9MiB 54.6%
Favor LZO 15% (-x favor_lzo -X 15) 15.14MiB/s 58.7% 54.9MiB 55.9% - 160.5MiB 53.2%
Favor LZO 10% (-x favor_lzo -X 10) 12.66MiB/s 49.1% 53.3MiB 54.3% - 156.5MiB 52.9%
zlib (-x zlib) 9.74MiB/s 37.7% 50.9MiB 51.8% 1.2MiB/s 151.7MiB 49.7%
zlib-JFFS2 (-x zlib, but hacked kernel and mkfs.ubifs) 9.39MiB/s 36.4% 51.8MiB 52.8% 1.7MiB/s 154.3MiB 51.1%

This table contains the results of 3 separate tests.

  1. Read test, where we measured read speed of a 98.2MiB file. The file contained various ARM libraries, executables from /bin and /sbin, and files from /etc. We created UBIFS images containing only this single file using using the mkfs.ubifs utility with various compression options. Then we measured read speed by reading whole 98.2MiB file on our ARM platform. So,
    • 1st column names the compressors and mkfs.ubifs options;
    • 2nd column lists file read speed;
    • 3rd column lists file read speed as percent of the uncompressed file read speed ([read_speed/25.81]*100%);
    • 4th column lists resulting UBIFS image sizes;
    • 5th column lists image sizes as percent of the uncompressed image size ([image_size/98.2MiB]*100%).
  2. Write speed test, where we wrote the same 98.2MiB file and synchronized the file system. And since favor LZO is mkfs.ubifs-only feature, it could not be tested, so
    • 6th column lists write speed.
  3. Rootfs image compression test, where we generated UBIFS image containing our root file system and compared resulting image sizes. So
    • 7th column lists sizes of our ARM rootfs images;
    • 8th column lists rootfs image sizes in percent of uncompressed rootfs image size ([image_size/301.8MiB]*100%).

UBIFS was mounted with "bulk_read" and "no_chk_data_crc" mount options.

The last row of the table contains the results of experimenting with JFFS2 zlib initialization parameters (see here) which are different to UBIFS compression parameters. We just temporarily hacked UBIFS and mkfs.ubifs to carry out the experiment.

As you may see from the table, zlib considerably slower on both compressing and decompressing comparing to LZO, while compression ratio only slightly better. You may also see that the favor LZO method may be used to balance speed and compression ratio, although the kernel is unable to write using favor LZO method (well, it'd be easy to implement this but write speed would drop a lot because the kernel would have to compress everything using both compressors). And because for our system the performance was more important, we selected LZO compressor.

UBIFS large block compression tests

UBIFS (just like JFFS2) compresses 4KiB data blocks, which means that all data is split on 4KiB chunks, and each chunk is compressed independently. Obviously, UBIFS could provide better compression if it used larger compression chunks, e.g. 8KiB or 16KiB. Implementing this would be difficult, but possible. But we tried to estimate how much of the improvement that would be and did the following:

The following table contains the results for LZO compressor.

Chunk size UBIFS image size Decrease (%) Absolute decrease (%) Decrease (MiB) Absolute decrease (MiB)
4KiB 209.1MiB (219211776 bytes) 0.0% 0.0% 0.0MiB 0.0MiB
8KiB 200.9MiB (210696192 bytes) 3.9% 3.9% 8.1MiB 8.1MiB
16KiB 194.9MiB (204374016 bytes) 3.0% 6.8% 6.0MiB 14.2MiB
32KiB 189.5MiB (198696960 bytes) 2.8% 9.4% 5.4MiB 19.6MiB
64KiB 185.7MiB (194697216 bytes) 2.0% 11.2% 3.8MiB 23.4MiB
128KiB 183.6MiB (192503808 bytes) 1.1% 12.2% 2.1MiB 25.5MiB
256KiB 182.6MiB (191471616 bytes) 0.5% 12.7% 1.0MiB 26.5MiB

The following table contains the results for zlib compressor.

Chunk size UBIFS image size Decrease (%) Absolute decrease (%) Decrease (MiB) Absolute decrease (MiB)
4KiB 189.5MiB (198696960 bytes) 0.0% 0.0% 0.0MiB 0.0MiB
8KiB 184.3MiB (193277952 bytes) 2.7% 2.7% 5.2MiB 5.2MiB
16KiB 181.7MiB (190568448 bytes) 1.4% 4.1% 2.6MiB 7.8MiB
32KiB 180.9MiB (189665280 bytes) 0.5% 4.5% 0.9MiB 8.6MiB
64KiB 180.6MiB (189407232 bytes) 0.1% 4.7% 0.2MiB 8.9MiB
128KiB 180.4MiB (189149184 bytes) 0.1% 4.8% 0.2MiB 9.1MiB
256KiB 180.4MiB (189149184 bytes) 0.1% 4.8% 0.2MiB 9.1MiB

The "decrease" column contains image size improvements comparing to the previous image, and the "absolute decrease" column contains image size improvements comparing to the standard image with 4KiB compression chunk size.

As you can see, LZO gives better improvement comparing to zlib when compression chunk size grows. Also, LZO with 32KiB compression chunk gives the same result as zlib with standard 4KiB compression chunk size, so it is questionable whether it makes sense to use the former. This depends on large compression chunks I/O speed penalty, but we do not have any numbers for this.

Thus, we figured out that large compression chunks support does not give much benefits for our system and did not implement this feature in UBIFS. However, for other systems this could give better improvements.

Last updated: 25 Oct 2008, dedekind Valid XHTML 1.0! Valid CSS!