Garbage collection thread

As a result of only performing garbage collection when needed, it can mean that individual writes to files may occasionally take a lengthy period of time to run if a new flash block is required - a whole flash block may need to be garbage collected from scratch, have its live data written to a new block, and be erased, the latter in particular being a very lengthy procedure. As such, JFFS2 offers the option of using a garbage collection thread, which can run in the background to advance the garbage collection process when the filesystem is not otherwise being used.

Of course if a filesystem is going to change too rapidly, or the application is CPU bound by higher priority threads, then the garbage collection thread may not be able to keep up. But for the majority of applications, it can considerably reduce or even virtually eliminate the delays caused by the requirement for occasional garbage collection.

The garbage collection thread can be enabled in the JFFS2 package's configuration using the "Garbage collection background thread" CDL option (CYGOPT_FS_JFFS2_GC_THREAD). The priority of that thread defaults to the lowest possible - 1 above that of the idle thread, but this can be changed with the CYGNUM_JFFS2_GC_THREAD_PRIORITY option. The thread of course requires a stack for execution, the value of which can be optimised with the CYGNUM_JFFS2_GC_THREAD_STACK_SIZE option. Note that one garbage collection thread is started for each mounted JFFS2 filesystem, and so one thread stack is allocated for each.

Usually the garbage collection thread will gradually garbage collect nodes from erase blocks until the block is completely unused by valid data. However it would not actually erase it, leaving that to the usual code path that erases blocks only at the point they are needed. This is because otherwise the Flash system may get locked for the duration of the erase process, preventing any threads, including high priority threads, access to it at that time. Yet the garbage collection thread is intended to be a low priority background thread. Nevertheless, enabling the option CYGSEM_JFFS2_GC_THREAD_CAN_ERASE allows the garbage collection thread to erase blocks as well, if blocks are available for erasure.

Finally, the garbage collection thread may run continuously but does not have to run constantly. By default, the thread will be inactive unless the amount of free space in the filesystem is beginning to run low. The filesystem code makes a judgement based on a myriad of factors to decide when to activate this background GC thread (although its low thread priority may result in it not running in practice, so choose its thread priority wisely in relation to the other running threads). Once active, the garbage collection thread will run until sufficient free space is now available, even if more garbage collection may be possible.

As a variation on this behaviour, it is possible to periodically wake the GC thread to advance garbage collection even when the available free space is not yet low; thus preventing it getting close to running out in the first place. This feature is controlled with the CYGNUM_JFFS2_GC_THREAD_TICKS configuration option, which gives the number of ticks between garbage collection passes, even when space is not low.

How ticks corresponds to real time is unspecified and depends on the HAL and kernel clock configuration (although most ports have traditionally defaulted to 10ms ticks). The value of this option can even be set to 0. Note though, that garbage collection is never considered "done" - the thread will run continuously until the filesystem is unmounted, therefore making it run too frequently may in fact cause unnecessary flash operations, increasing flash wear (even though it will be levelled wear). The value should be chosen according to the expected write pattern.

The number of ticks between garbage collection passes can also be set at runtime, by invoking a cyg_fs_setinfo() call on a filesystem object. There is a corresponding cyg_fs_getinfo() call to retrieve the current delay ticks. For example:

#include <cyg/fs/jffs2/jffs2.h>
    …
    {
        int err;
        cyg_tick_count_t old_delay_ticks;
        cyg_tick_count_t new_delay_ticks;

        err = cyg_fs_getinfo( "/jffs2",
                              FS_INFO_JFFS2_GET_GC_THREAD_TICKS,
                              &old_delay_ticks,
                              sizeof(cyg_tick_count));
        assert(err == 0);
        new_delay_ticks = old_delay_ticks*10; // slow down GC
        err = cyg_fs_setinfo( "/jffs2",
                              FS_INFO_JFFS2_SET_GC_THREAD_TICKS,
                              &new_delay_ticks,
                              sizeof(cyg_tick_count));
        assert(err == 0);
    }

One application of dynamically setting the wakeup delay for the garbage collection thread is so that the thread is more active in times of relative system activity, but operates more slowly when quiescent. This may improve flash life, while still retaining benefits of the garbage collection thread.

The value of the wakeup delay can be set to a special value of (cyg_tick_count_t)-1, which indicates that the thread should not wake up periodically any more, but only when space is running low (the behaviour when CYGNUM_JFFS2_GC_THREAD_TICKS is disabled). Similarly retrieving the current wakeup tick value with cyg_fs_getinfo() may return this special value.

Write size

JFFS2 does not guarantee 100% optimal use of Flash space due to its journalling nature, and the granularity of Flash blocks. It is possible for it to fill up even when not all file space appears to have been used, especially if files have had many small operations performed on them and the Flash partition is small compared to the size of the Flash blocks. It is strongly recommended to have at least 5 or 6 Flash blocks spare, over and above space requirements for data, in order to allow the JFFS2 garbage collector to operate.

It is certainly the case that JFFS2 will work very inefficiently if using many small writes. Unless and until garbage collected, each write will occupy its own JFFS2 node on Flash, and so will incur overhead from the node header. A filesystem is likely to "fill" quickly if written a few bytes at a time, rather than in large chunks, so caution in advised, and more space reserved if that write pattern is anticipated. A common application that can do this is logging. Small writes can also remove the benefits of compression, as there is too little data to compress effectively.

Garbage collection

Use of the garbage collection thread will provide a level of continuous garbage collection. As indicated above, garbage collection can reduce flash usage and memory consumption, and improve performance. Therefore doing so on a continuous basis is a wise idea.

Extra spare space is required in order to allow the JFFS2 garbage collector to operate, over and above space requirements for data. A rule of thumb is to use the following formula:

Recommended overhead == 2 + (( flashsize/50 ) + (flashsectors*100) + (sectorsize-1)) / sectorsize 

So for example, a 16Mbyte flash with 64Kbyte blocks given over entirely to JFFS2 would actually require an overhead of 6 blocks. Or to look at it another way, trying to write data when you have used up all but 6 blocks worth may result in an ENOSPC error being reported. Due to metadata and write characteristics (e.g. lots of 1 byte writes) it's not possible to easily calculate what that actually translates to in terms of maximum file size. Even the above formula is only a rule of thumb, and it has not been proven to be guaranteed to work in all circumstances. It is recommended to be conservative if possible.

Compression

JFFS2 will default to trying to compress files. However, it may be more memory efficient to disable JFFS2 compression entirely in the CDL configuration, and instead ensure that images are stored compressed when they are downloaded, and use the standard RedBoot mechanism to decompress the files upon loading.

Maximum data node size

By default JFFS2 will operate on chunks of files up to 4 kilobytes in size, but larger chunks may be able to be compressed more efficiently, and have lower metadata overheads. To increase the size, you must change JFFS2's view of the machine page size - the eCos JFFS2 port's view of the page size does not actually need to reflect any real underlying page size of the memory management system, and the notion of the page size is a hangover from the Linux origins of JFFS2 which would be too disruptive to remove. Changing the page size can be performed by changing the page size exponent configuration option (CYGNUM_LINUX_COMPAT_PAGE_SIZE_EXPONENT) in the Linux compatibility layer package (CYGPKG_LINUX_COMPAT). A value of 12 indicates 2¹² which is 4 kilobytes. For example this could be changed to 16, corresponding to 2¹⁶ which is 64 kilobytes. If using mkfs.jffs2, make sure that its value for the page size, using the -s or --pagesize options, is the same or lower than the page size given by CYGNUM_LINUX_COMPAT_PAGE_SIZE_EXPONENT.

Methodology

Because obsolete data for a file could exist in any block, the only way to achieve this is to ensure that every block (other than bad or completely free blocks) is wiped, taking care to relocate live data. This effectively means methodically garbage collecting and erasing every flash block used by the filesystem.

Operation time

For a filesystem which almost completely consists of used flash blocks the secure erase process could take a considerable amount of time during which the filesystem cannot be used for other operations. Therefore it is strongly recommended that the garbage collection thread support is enabled with an appropriate value for CYGNUM_JFFS2_GC_THREAD_TICKS. With the garbage collection thread running, more blocks are likely to be completely clean, or at least partially garbage collected, thus reducing the time for secure erasure.

Usage

Support for the secure erase functionality must first be enabled with a CDL configuration option - CYGOPT_FS_JFFS2_SECERASE.

Then a secure erase operation can be performed on the filesystem with a cyg_fs_setinfo() function call using the FS_INFO_SECURE_ERASE config key. This call can be invoked specifying any file or directory within the filesystem including its mount point, although the operation itself will take place on the entire filesystem.

#include <cyg/fileio/fileio.h>
#include <errno.h>
#include <stdio.h>
    …
    int err;
    err = cyg_fs_setinfo("/fs", FS_INFO_SECURE_ERASE, NULL, 0);

    if (ENOERR != err)
    {
      printf( "Secure erase failed: %d\n", strerror(err) );
      …