Home FAQ Mailing Lists / IRC Source Documentation Misc Archive Fellows

Memory Technology Devices

UBIFS FAQ and HOWTO

May UBIFS be used on MLC NAND flash?

UBIFS authors never tested UBI/UBIFS on MLC flash devices. However, it should run fine. Let's consider some specific aspects of MLC NAND flashes:

MLC NAND flashes are more "faulty" than SLC, so they use stronger ECC codes which occupy whole OOB area; this is not a problem for UBI/UBIFS, because neither UBIFS nor UBI use OOB area;
when the data is written to an eraseblock, it has to be written sequentially, from the beginning of the eraseblock to the end of it; this is also not a problem because it is exactly what UBI and UBIFS do (see also this section);
MLC flashes have rather short eraseblock life-cycle of just few thousand of erase cycles; and this is not a problem, because UBI uses deterministic wear-leveling algorithm (see this section);
MLC flashes have so called "read-disturb" property, which means that NAND page read operation may introduce a permanent bit change; the ECC code would fix it, but more read operations may introduce more bit changes and soft ECC errors may turn into hard ECC errors; well, even SLC NAND flashes have this property, but the probability of bit changes is much lower in SLC NAND; however, this should not be a problem because UBI is doing scrubbing; in other words, once UBI notices that there is a correctable bit-flip in an eraseblock, it moves the contents of this physical eraseblock to a different physical eraseblocks, and re-maps corresponding logical eraseblocks to the new physical eraseblock; so UBI refreshes the data and gets rid of bit-flips, thus improving data integrity.

However, there are 2 other aspects which may need closer attention. The first one is the "paired pages" problem (e.g., see this Power Point presentation). Namely, MLC NAND pages are coupled in a sense that if you cut power while writing to a page, you corrupt not only this page, but also one of the previous pages which is paired with the current one. For example, pages 0 and 3, 1 and 4, 2 and 5, 3 and 6 in and so on (in the same eraseblock) may be paired (page distance is 4, but there may be other distances). So if you write data to, say, page 3 and cut the power, you may end up with corrupted data in page 0. UBIFS is not ready to handle this problem at the moment and this needs some work.

The second aspect is the "program-disturb" MLC NAND property (see here), which means that if you program an MLC NAND page, you may introduce a bit-change in a different NAND page. Well, the bit change will be fixed by ECC, but with time the changes may accumulate and become unfixable. Current UBI bit-flip handling only partially helps here, because it is passive, which means that UBI notices bit-flips only when performing users read requests, so if you never read the MLC NAND area which accumulates bit-flips, UBI will never notice this. However, it is not difficult to implement a kind of "flash crawler" which would read the flash in background from time to time and make UBI notice and fix bit-flips.

Nevertheless, UBIFS authors never worked with real raw MLC NAND flash, so we might have missed or misinterpreted some MLC NAND aspects. Any feed-back is appreciated.

How to mount UBIFS?

UBIFS mounts UBI volumes, not UBI devices, not MTD devices. There are no block device nodes corresponding to UBI volumes and UBIFS uses device-less mount, just like procfs or sysfs. The volume to mount is specified using ubiX_Y or ubiX:NAME syntax, where

X - UBI device number;
Y - UBI volume number;
NAME - UBI volume name.

For example,

$ mount -t ubifs ubi1_0 /mnt/ubifs

mounts volume 0 on UBI device 1 to /mnt/ubifs, and

$ mount -t ubifs ubi0:rootfs /mnt/ubifs

mounts "rootfs" volume of UBI device 0 to /mnt/ubifs ("rootfs" is volume name). This method of specifying UBI volume is more preferable because it does not depend on volume number.

Note, if X is not specified, UBIFS assumes 0, i.e., "ubi0:rootfs" and "ubi:rootfs" are equivalent.

Some environments like busybox are confused by the ":" delimiter (e.g., ubi:rootfs) and "!" may be used instead (e.g., ubi!rootfs).

In order to mount UBIFS as the root file system, you have to compile UBIFS into the kernel (instead of compiling it as a kernel module) and specify proper kernel boot arguments and make the kernel mount UBIFS on boot. You have to provide the boot arguments to attach the UBI device (using the ubi.mtd= argument, see here). Then you should tell the kernel the file system type by prividing the rootfstype= argument. And finally, you should specify which UBI volume has to be mounted on boot using the root= argument. The volume is specified the same way as described above (ubiX_Y or ubiX:NAME).

The following is an example of the kernel boot arguments to attach mtd0 to UBI and mount UBI volume "rootfs":

ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs

Please, see this section for information about how to create UBI devices and this section for information about how to create UBI volumes.

How to create an UBIFS image?

Creating UBIFS images might be a little trickier than creating JFFS2 images. First of all, you have to understand that UBIFS works on top of UBI which works on top or MTD which basically represents your raw flash. This means, that if you need to create an image which would be flashed to the raw flash, you should first create an UBIFS image, than UBI image. In other words, the process has 2 steps.

However, as described here, UBI has a volume update facility and there is an ubiupdatevol utility for this. So you may update UBI volumes on your running system as well. In this case you only need an UBIFS image, and you do not have to make the UBI image, i.e., the process has only 1 step in this case.

So, there are 2 utilities:

mkfs.ubifs which creates UBIFS images;
ubinize which creates UBI images out of UBIFS images.

And depending on the needs you use either mkfs.ubifs or mkfs.ubifs plus ubinize. Choose the former if you are going to upload the update UBIFS image on your target and then update the UBI volume using ubiupdatevol. Choose the latter if you are going to flash the image to raw flash, e.g., at the factory.

The UBI and UBIFS images depend on parameters of the flash they are going to be used on. Namely, you have to know the following characteristics of the flash before creating images:

flash size;
physical eraseblock size;
minimum flash input/output unit size;
for NAND flashes, sub-page size;
logical eraseblock size.

This and this sections explain the above parameters and give some hints about how to find them out.

And optionally, you should decide which compression algorithm you would want to use for this file-system. UBIFS supports zlib and LZO (default) at the moment (see here). There is also favor LZO mkfs.ubifs compression method. Generally, zlib compresses better, but it is slower on both compression and decompression. So this is a trade-off between space savings and speed. The best idea is to try both and choose the one which is more appropriate for you. Here you may find compression test results for ARM platform. Alternatively, the compression may be switched off. See "-x" option of the mkfs.ubifs utility.

There are other advanced file-system and UBI characteristics which may be altered with various options of the tools. Use them only if you understand what they do.

The below example demonstrates how to create an UBI/UBIFS image for a 256MiB SLC OneNAND flash chip with 128KiB physical eraseblocks, 2048 bytes NAND pages, and supporting 4 sub-pages (this means that it allows to do 4x512 bytes writes to the same NAND page, which is quite typical for SLC flashes). The resulting image will have only one UBI volume storing UBIFS file-system.

$ mkfs.ubifs -r root-fs -m 2048 -e 129024 -c 2047 -o ubifs.img
$ ubinize -o ubi.img -m 2048 -p 128KiB -s 512 ubinize.cfg

where ubinize.cfg contains:

$ cat ubinize.cfg
[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=200MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize

Some comments about what the options mean:

-r root-fs: tells mkfs.ubifs to create an UBIFS image which would have identical contents as the local root-fs directory;
-m 2048: tells mkfs.ubifs that the minimum input/output unit size of the flash this UBIFS image is created for is 2048 bytes (NAND page in this case);
-e 129024: logical eraseblock size of the UBI volume this image is created for;
-c 2047: specifies maximum file-system size in logical eraseblocks; this means that it will be possible to use the resulting file-system on volumes up to this size (less or equivalent); so in this particular case, the resulting FS may be put on volumes up to about 251MiB (129024 multiplied by 2047); See this section for more details.
-p 128KiB: tells ubinize that physical eraseblock size of the flash chip the UBI image is created for is 128KiB (128 * 1024 bytes);
-s 512: tells ubinize that the flash supports sub-pages and sub-page size is 512 bytes; ubinize will take this into account and put the VID header to the same NAND page as the EC header.

The ubinize utility requires volumes description file. Please, refer this section for more ubinize usage information.

In the example, the ubinize.cfg file tells ubinize to create an UBI image which has a singe 200MiB dynamic volume with ID 0, and name "rootfs". The configuration file also sets the "autoresize" volume flag, which means that the volume will be automatically enlarged by UBI to have the maximum possible size when it runs for the first time. See here for more information about what the auto-resize feature is. And because we specified "-c 2047" mkfs.ubifs option, UBIFS will also automatically re-size on the first mount. So the end result will be that you have one single volume of maximum possible size, and UBIFS spans whole volume.

Please, run ubinize -h and mkfs.ubifs -h for more information and for more possibilities to tweak the generated images.

Here is one more example for a 32MiB NOR flash with 128KiB physical eraseblock size.

$ mkfs.ubifs -r root-fs -m 1 -e 130944 -c 255 -o ubifs.img
$ ubinize -o ubi.img -m 1 -p 128KiB ubinize.cfg

where ubinize.cfg contains:

$ cat ubinize.cfg
[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=30MiB
vol_type=dynamic
vol_name=rootfs
vol_alignment=1
vol_flags=autoresize

And one more example for a 512MiB MLC NAND flash with 128KiB physical eraseblock size, 2048 bytes NAND page size and no sub-page write support.

$ mkfs.ubifs -r root-fs -m 2048 -e 126976 -c 4095 -o ubifs.img
$ ubinize -o ubi.img -m 2048 -p 128KiB ubinize.cfg

where ubinize.cfg contains:

$ cat ubinize.cfg
[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=450MiB
vol_type=dynamic
vol_name=rootfs
vol_alignment=1
vol_flags=autoresize

To flash UBI images, please use the ubiformat utility (see here) or use/implement a custom flasher program (here you may find some hints).

How to find out LEB size?

When creating UBIFS images it is necessary to know logical eraseblock size which depends on the following flash chip parameters:

physical eraseblock size;
minimum input/output unit size;
sub-page size;

Please, refer this section for more information about how to find those 3 parameters. Here are the most typical configurations:

NOR flash with 1 byte min. I/O unit size: LEB size is PEB size minus 128;
NAND flash with 512 byte NAND page and 265 byte sub-page: LEB size is PEB size minus 512;
NAND flash with 2048 byte NAND page and 512 byte sub-page: LEB size is PEB size minus 2048;
NAND flash with 2048 byte NAND page and no sub-page: LEB size is PEB size minus 4096.

Please, also refer this section for additional information.

The simplest way to find out the LEB size is to attach the MTD device to UBI, as it is suggested at the end of this section.

Is it OK to mount empty UBI volumes?

Yes, it is OK to mount empty UBI volumes, i.e. the volumes which contain only 0xFF bytes. In this case UBIFS formats the media automatically with default parameters (journal size, compression, etc). But generally, this feature should have limited use (developing, debugging), and a proper UBIFS image should preferably be created and flashed (see this section).

Note, UBI has similar property and it automatically formats the flash media if it is empty (see here). So if there is an mtd0 MTD device, the following will work:

# Wipe the MTD device out. Note, we could use flash_eraseall, but we do not
# want to loose erase counters
ubiformat /dev/mtd0

# Load UBI module
modprobe ubi

# Attach mtd0 to UBI - UBI will detect that the MTD device is
# empty and automatically format it. This command will also create
# UBI device 0 and udev should create /dev/ubi0 node
ubiattach /dev/ubi_ctrl -m 0

# Create an UBI volume - the created volume will be empty
ubimkvol /dev/ubi0 -N test_volume -s 10MiB

# Mount UBIFS - it will automatically format the empty volume
mount -t ubifs ubi0:test_volume /mnt/ubifs

It is also possible to wipe out an existing UBIFS volume represented by /dev/ubi0_0 using the following command:

ubiupdatevol /dev/ubi0_0 -t

What is the purpose of -c (--max-leb-cnt) mkfs.ubifs option?

It is a form of specifying file-system size. But instead of specifying the exact file-system size, this option defines the maximum file-system size (more strictly, maximum UBI volume size). For example, if you use --max-leb-cnt=200 mkfs.ubifs option, than it will be possible to put the resulting image to smaller UBI volume and mount it. But if the image is put to a larger UBI volume, the file-system will anyway take only first 200 LEBs, and the rest of the volume will be wasted.

Note, the --max-leb-cnt option does not affect the size of the resulting image file, which depends only on the amount of data in the file-system. mkfs.ubifs just writes the --max-leb-cnt value to the file-system superblocks.

This feature is quite handy on NAND flashes, because they have random amount of initial bad eraseblocks (marked as bad in production). This means, that different devices may have slightly different volume sizes (especially if the UBI auto-resize feature is used). So you may specify the maximum possible volume size and this will guarantee that the image will work on all devices, irrespectively on the amount of initial bad eraseblocks.

Fundamentally, mkfs.ubifs has to know file-system size because UBIFS maintains and stores per-LEB information (like amount of dirty and free space in each LEB) in so-called LPT area on the media. So obviously, the size of this area depends on the total amount of LEBs, i.e. on the volume size. Note, various characteristics of the LPT B-tree depend on the LPT area size, e.g., we use less bits in LPT tree keys of smaller LPT area. So do not use unnecessarily large --max-leb-cnt value to achieve better performance.

Can UBIFS mount loop-back devices?

Unfortunately not, because loop-back devices are block devices (backed by regular files), while UBIFS works on top of UBI devices (see here).

However, there is a very hacky way to make UBIFS work with a file-backed image using NAND simulator (see here). Originally nandsim has been created to emulate NAND flashes in RAM, but there is a patch which teaches nandsim to use a file instead of memory. Try something like

# Create a 1GiB emulated MTD device backed by regular file "my_image"
$ modprobe nandsim cache_file=my_image first_id_byte=0xec second_id_byte=0xd3 third_id_byte=0x51 fourth_id_byte=0x95

See here for more instructions about using UBIFS with nandsim.

But be warned that this patch has not been well tested, it is not in mainline yet, and it has been created for development and debugging purposes, but not for production use.

What is "favor LZO" compression?

Starting from version 1.1, the mkfs.ubifs utility supports so-called "favor LZO" compression. This is not a new compression algorithm, it is just a method of combining LZO and zlib compressors to balance speed and compression ratio. A similar method exists in the mkfs.jffs2 utility, and we borrowed this idea from there.

As this documentation section highlights, zlib compressor provides better compression ratio comparing to the LZO compressor, but it is considerably slower, especially on embedded platforms which do not usually have powerful CPUs. The favor LZO compression method makes it possible to use zlib compressor for data chunks which zlib may compress much better than LZO, and to use LZO compressor for data chunks which zlib compresses only slightly better than LZO. See this section for some favor LZO experiment results on ARM platform.

Here is the favor LZO algorithm. Each 4KiB data chunk is compressed by both zlib and LZO compressors. If zlib compresses at least 20% better than LZO, then zlib is used for this data chunk. Otherwise, LZO is used. Very simple. The 20% threshold is configurable via the "-X mkfs.ubifs option, so you may make it 10% or anything else. Example:

$ mkfs.ubifs -r rootfs -m 2048 -e 129024 -c 2047 -x favor_lzo -X 5 -o ubifs.img

This command creates an UBIFS image containing the rootfs directory, using favor LZO compression with threshold 5%. This means that if a data chunk compresses at least 5% better with zlib, then mkfs.ubifs uses zlib, otherwise it uses LZO.

So UBIFS images created with favor LZO compression will contain both LZO and zlib-compressed data nodes. However, the default file-system compressor will be LZO. This means, the kernel will use LZO compressor for all data. This is because the favor LZO method is not implemented in-kernel, just because UBIFS authors did not need it there. Of course you can mount the UBIFS images created with the favor LZO compression method, and they will work fine. But if you write a file to the UBIFS file-system, it will be compressed only by the LZO compressor. So favor LZO is actually useful only for read-only files which are not going to be over-written. However, it should be easy to implement favor LZO in the kernel.

How to compile mkfs.ubifs?

The mkfs.ubifs utility requires zlib, lzo and uuid libraries. The former two are used for compressing the data, and the latter one is used for generating universally unique ID number for the file-system. In Fedora install zlib-devel, lzo-devel, and e2fsprogs-devel (libuuid is provided there, strangely) packages, in Debian install zlib1g-dev, liblzo2-dev and uuid-dev packages.

How to change a file atomically?

Changing a file atomically means changing the contents in a way that unclean reboots could not lead to any corruption or inconsistency in the file. The only reliable way to do this in UBIFS (and in most of other file-systems, e.g. JFFS2 or ext3) is the following:

make a copy of the file;
change the copy;
synchronize the copy (see here);
re-name the copy to the file (using the rename() libc function or mv utility).

Note, if power-cut happens during re-naming, the original file will be intact. This is POSIX requirement and UBIFS satisfies it.

Does UBIFS support atime?

No, it does not support atime. The authors think it is not very useful in embedded world and did not implement this. Indeed most of the users do not provably want the file-system doing inode updates every time they are read.

Does UBIFS support NFS?

Not so far, but it is planned to be implemented.

Does UBIFS become slower when it is full?

Yes, UBIFS writes (but not reads) become slower when it is full or close to be full. There are 2 main reasons for this:

Garbage Collection becomes slower, because the small pieces of dirty space are distributed all over the media, and UBIFS Garbage Collector has to move many eraseblocks to produce one free eraseblock; this is a fundamental reason and it exists in JFFS2 as well;
The file-system becomes more synchronous; UBIFS buffers dirty data, but due to compression and some other factors like wasting small pieces of space at the end of eraseblocks, UBIFS does not exactly know how much space the buffered dirty data would take on the flash media, so it uses pessimistic calculations and assumes that the data is uncompressible. In many cases this is not true, but UBIFS has to assume worst-case scenario. So when all free space on the file-system is reserved for the buffered dirty data, but users want to write more, UBIFS forces write-back to actually write the buffered dirty data and see how much space will be available after that. Then UBIFS may allow new data to be written. Thus, it is obvious that the less free flash space is available, the less dirty data may be buffered, and the more synchronous the file-system becomes.

Note, also slows down when it is close to being full, but UBIFS should be better than JFFS2 in this respect (slow down less). This is because UBIFS always chooses optimal LEBs to garbage-collect, while JFFS2 may choose random eraseblocks.

Why `df` reports too few free space?

UBIFS flash space accounting is quite challenging and it is not always possible to report accurate amount of free space. The df utility usually reports less free space than users may actually write to the file-system, but it never reports more space.

UBIFS cannot precisely predict how much data the user will be able to write to the file-system. There are several reasons for this - compression, write-back, space wastage at the end of logical eraseblocks, garbage-collection, etc. Please, refer this section for details.

Note, JFFS2 also has problems with free space predictions, but in average, it reports much more accurate amount of free space. However, JFFS2 may lie and report more free space than it actually has. For example, we experienced situations when JFFS2 reported 8MiB free space, while we were able to write only 2 MiB of data. This makes some user-space applications very unhappy.

UBIFS also lies, but it always report less space that user may actually write. For example, it may report 2MiB of free space, but if you start writing to it, may be able to write 4MiB there (even if you have compression disabled).

Thus, the only way to find out precise amount of free space is to fill up the file-system and see how much has been written. Try something like this:

$ touch /mnt/ubifs/file
$ chattr -c /mnt/ubifs/file # Disable compression for this file
$ dd if=/dev/zero of=/mnt/ubifs/file bs=4096

# Presumably random data does not compress
dd if=/dev/urandom of=/mnt/ubifs/file bs=4096

and see the size of the file. And do not forget that some space is reserved for the super-user (see here), so it is better to be the root.

UBIFS users should know that the more dirty cached FS data is there, the less precise is the df report. Try to create a big file, and look at the df report. Then synchronize the file-system (using the sync command) and look at the df report again. You should notice that df reports more free space after the synchronization. Here is an example:

# Create a 64MiB uncompressible file
$ dd if=/dev/urandom of=/mnt/ubifs/file bs=8192 count=8192
$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
ubi0:ubifs              117676     68880     43736  62% /mnt/ubifs

$ sync
$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
ubi0:ubifs              117676     64304     48308  58% /mnt/ubifs

Notice that the amount of free space increased by 4%. However, that was an uncompressible file. Here is a similar example, but which uses a file which compresses well:

# Create a 64MiB file containing zeroes
$ dd if=/dev/zero of=/mnt/ubifs/file bs=8192 count=8192
$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
ubi0:ubifs              117676     69312     43304  62% /mnt/ubifs

$ sync
$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
ubi0:ubifs              117676      7052    105564   7% /mnt/ubifs

If instead of synchronizing the file-system you just watch how the df report is changing, you will notice that the amount of free space continuously grows until reaches its final value. This happens because the kernel starts writing the dirty data back by time-out (5 sec by default) and the amount of dirty data goes down, making the df report more precize.

If you want to have as precise free space prediction as possible - synchronize the file-system. This not only flushes dirty data to the media, this also commits UBIFS journal, which improves free space prediction even more. The other possibility is to mount UBIFS in synchronous mode using -o sync mount option. However, it may perform not as well as in asynchronous (default) mode.

It is also worth noting that the closer is UBIFS to being full, the less accurate is free space reporting.

To conclude:

do not trust df free space reports;
df reports less free space in most cases;
if df reports X bytes of free space, you are guaranteed to be able to write at least X bytes of data to a file, but usually more than X bytes;
run sync to get the most accurate df report; alternatively, you may mount UBIFS in synchronous mode using -o sync mount option;
read this section if you are curious why UBIFS has issues with df.

How to disable compression?

UBIFS compression may be disabled for whole file system during the image creation time using the "-x none" mkfs.ubifs option. However, if UBIFS compression is enabled, it may be disabled for individual files by cleaning the inode compression flag:

$ chattr -c /mnt/ubifs/file

in shell, or

/* Get inode flags */
ioctl(fd, FS_IOC_GETFLAGS, &flags);
/* Set "compression" flag */
flags &= ~FS_COMPR_FL;
/* Change inode flags */
ioctl(fd, FS_IOC_SETFLAGS, &flags);

in C programs. Similarly, if compression is disabled by default, you may enable if for individual inodes by setting the compression flag. Note, the code which uses the compression flag works fine on other Linux file-systems, because the flag is just ignored in this case.

It might be a good idea to disable compression for say, mp3 or jpeg files which would anyway not compress and UBIFS would just waste CPU time trying to compress them. The compression may also be disabled if one wants faster file I/O, because UBIFS would not need to compress or decompress the data on reads and write. However, I/O speed may actually become slower if compression is disabled. Indeed, in case of a very fast CPU and very slow flash compressed writes are faster, but this is usually not true for embedded systems.

How to use UBIFS with nandsim?

The same way as with any MTD device. Here is an example of how to load nandsim, create an UBI volume and mount it.

# Create an 256MiB emulated NAND flash
modprobe nandsim first_id_byte=0x20 second_id_byte=0xaa \
                 third_id_byte=0x00 fourth_id_byte=0x15

# MTD is not LDM-enabled and udev does not create device
# MTD device nodes automatically, so create /dev/mtd0
mknod /dev/mtd0 c 90 0

# Load UBI module and attach mtd0
modprobe ubi mtd=0

# Create a 200MiB UBI volume with name "ubifs-vol"
ubimkvol /dev/ubi0 -N ubifs-vol -s 200MiB

# Mount UBIFS
mount -t ubifs ubi0:ubifs-vol /mnt/ubifs

For more information about nandsim see here.

Is UBIFS tolerant to power-cuts?

Yes, both UBI (see here) and UBIFS are tolerant to power-cuts, and they were designed with this property in mind.

UBIFS has internal debugging infrastructure to emulate power failures and the authors used it for extensive testing. It was tested for long time with power-fail emulation. The advantage of the emulation is that it emulates power failures even at the situations which happen not very often. For example, when the master node is updated, or the log is changed. The probability to interrupt the system at those moments is very low in real-life.

Real power-cut tests have also been done on OneNAND flash. We used Power Node devices which are controlled via serial line and may switch the power of the connected device on and off. UBIFS survived more than 20000 power-cuts while running stress tests.

I need more space - should I make UBIFS journal smaller?

UBIFS journal is very different to ext3 journal. In case of ext3, the journal has fixed position on the block device. The data is first written to the journal, and then copied to the file-system. This copying is done during the commit. After the commit, new data may be written to the journal, and so on. So in case of ext3 changing journal size would change file-system capacity.

The situation is different in UBIFS. UBIFS journal is "wandering". It does not have fixed position in the UBI volume. When the journal is full, UBIFS is committing it which means it simply amends the FS index to refer the data which is stored in the journal. Then different LEBs are picked for the new journal, and so on. So the journal constantly migrates. The journal contains the same information as other data LEBs, but this information is just not referred from the index, it is not indexed. But there is flash space reserved for the indexing information, and this space is used during commit.

In other words, if your file-system is full, the journal will also be full and contain data. And the situation does not really change if you vary journal size.

To put it simple, the amount of available space on UBIFS does not really depend on the journal size. There is very weak dependency, though, because for bigger journal we need bigger log, but it is really something which does not make any noticeable difference.

UBIFS suddenly became read-only - what is this?

Read-write UBIFS file-system may suddenly become read-only because of an error. This is how UBIFS reacts on unexpected errors which it cannot properly handle - it immediately switches to read-only mode in order to protect the data from any possible further corruption.

If this happened, you should look at UBIFS-related dmesg messages. UBIFS usually prints error messages before switching to read-only mode. The messages may shed some light on what happened. Feel free to ask for help from the MTD mailing list. If you think this is an UBIFS bug, please, send a bug report.

I want to study UBIFS - any recommendations?

Follow these instructions.

UBIFS FAQ and HOWTO

Table of contents