This page contains various MTD-related information which does not fit the FAQ or Documentation categories.
Table of contents
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.
- Read test, where we measured read speed of a 98.2MiB file. The file
contained various ARM libraries, executables from
/binand/sbin, and files from/etc. We created UBIFS images containing only this single file using using themkfs.ubifsutility 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.ubifsoptions; - 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%).
- 1st column names the compressors and
- 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.
- 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:
- hacked the
mkfs.ubifsutility and made it generate UBIFS images with large compression chunk sizes - 8KiB, 16KiB, 32KiB and so on; here is the patch which implements the hack; - generated UBIFS images of our root file-system with various compression chunk sizes; the root file system was ARM rootfs and contained Debian-based Maemo stuff;
- generated UBIFS images with both LZO and zlib compressors with 4KiB-256KiB compression chunk sizes.
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.
