Dear Charles,

I'm trying the last version of yaffs after some time of inactivity. It looks great, with background collection and block refreshing, and the granularity of collection has been decreased so collection can be interrupted more quickly. This seems to solve my previous concerns about wear leveling and quick reaction on power fail.

I have one new concern now. This is the result of some experimenting and studying the code. Please forgive me if I didn't get it right, the GC code is rather complex.

I've noticed that after a while all dirty blocks get erased, even if they have just a single unused chunk, due to this code in yaffs_find_gc_block():

    /*
     * If nothing has been selected for a while, try the oldest dirty
     * because that's gumming up the works.
     */

    if (!selected && dev->param.is_yaffs2 &&
        dev->gc_not_done >= (background ? 10 : 20)) {
        yaffs2_find_oldest_dirty_seq(dev);
        if (dev->oldest_dirty_block > 0) {
            selected = dev->oldest_dirty_block;
            dev->gc_dirtiest = selected;
            dev->oldest_dirty_gc_count++;
            bi = yaffs_get_block_info(dev, selected);
            dev->gc_pages_in_use =
                bi->pages_in_use - bi->soft_del_pages;
        } else {
            dev->gc_not_done = 0;
        }
    }

If no block is selected for erasure when this code is executed, this means that there are enough erased blocks and no dirty block with enough garbage was found. Then one out of 10 or 20 times the oldest dirty block is selected and erased anyway.

I'm not sure about the rationale behind this code. I guess it tends to keep the nand flash de-fragmented, since in the long run it will elliminate all garbage. But I'm concerned about the amount of erasures caused by this logic. I ran a test on a 128 MB partition which was like 40 % full and 60 % free. I just created and deleted a a very small file several times, each time waiting for yaffs to stabilize until no more blocks were erased (I was checking erasures by tracing). I'm aware this is the least friendly thing to do, because it does not allow yaffs to "consolidate" successive changes.

Now /proc/yaffs reads as follows:
Multi-version YAFFS built:Mar 21 2011 16:41:07


Device 0 "nand_filesystem"
start_block.......... 0
end_block............ 999
total_bytes_per_chunk 2048
use_nand_ecc......... 1
no_tags_ecc.......... 0
is_yaffs2............ 1
inband_tags.......... 0
empty_lost_n_found... 0
disable_lazy_load.... 0
refresh_period....... 500
n_caches............. 10
n_reserved_blocks.... 5
always_check_erased.. 0

data_bytes_per_chunk. 2048
chunk_grp_bits....... 0
chunk_grp_size....... 1
n_erased_blocks...... 571
blocks_in_checkpt.... 1

n_tnodes............. 2409
n_obj................ 241
n_free_chunks........ 36581

n_page_writes........ 3241
n_page_reads......... 3108
n_erasures........... 55
n_gc_copies.......... 3088
all_gcs.............. 645
passive_gc_count..... 645
oldest_dirty_gc_count 50
n_gc_blocks.......... 51
bg_gcs............... 51
n_retired_writes..... 0
n_retired_blocks..... 0
n_ecc_fixed.......... 0
n_ecc_unfixed........ 0
n_tags_ecc_fixed..... 0
n_tags_ecc_unfixed... 0
cache_hits........... 0
n_deleted_files...... 0
n_unlinked_files..... 64
refresh_count........ 1
n_bg_deletions....... 0

There have been 55 block erasures; one of them is a block refresh and 50 are "oldest dirty block" erasures. This leaves us with only 4 "good" erasures of blocks with a reasonable amount of garbage. Tracing showed that the 50 "oldest dirty" erasures were performed on blocks with very little garbage, many times just one chunk. At first sight this looks excessive, considering that more than half of the blocks in the flash are empty. The difference in flash wear is big (around 10 to 1 in this case).

What do you think? Maybe increasing the skip values (10 and 20) so that the "oldest dirty" code runs less frequently will give a better balance between long-term de-fragmentation and too many erasures?

Best regards,
Hugo

--
Grupo Hasar

Ing. Hugo Eduardo Etchegoyen
Gerente Dto. Software de Base

Compañía Hasar | Grupo Hasar
Marcos Sastre y José Ingenieros
El Talar. Pacheco
[B1618CSD] Buenos Aires. Argentina
Tel [54 11] 4117 8900 | Fax [54 11] 4117 8998
E-mail: hetchegoyen@hasar.com
Visítenos en: www.hasar.com
Información legal y política de confidencialidad: www.grupohasar.com/disclaimer