Hi all,

Sorry for insisting... I posted a previous mail on this subject but I did'nt get any reply.

I have a couple of concerns about the GC logic.

I've noticed 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 I understand it properly, if no block is selected for erasure when this code is executed (meaning aggressive = false and no dirty block with enough garbage was found), then one out of 10 or 20 times the oldest dirty block will be selected.

These are my concerns:

1) I guess that this is done for de-fragmenting the flash, i.e. elliminating all garbage. But I don't understand why the cleaning code should  choose the oldest dirty block first and not just the dirtiest, since erasing old blocks is already being taken care of by the block refresh logic. Maybe I'm missing some other reason behind this code.

2) This logic increases flash wear. I ran a test on a 128 MB partition which was more or less 40 % full and 60 % free. I just created and deleted 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).

After that /proc/yaffs read 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 other 50 ones are "oldest dirty block" erasures due to the code quoted above. This leaves only 4 "good" erasures of blocks with a reasonable amount of garbage. So de-fragmentation has increased flash wear by more than ten fold. Tracing showed that the 50 "oldest dirty" erasures were performed on blocks with very little garbage, many times just one chunk.

The problem arises when this code is run in the background thread, since it runs at a fixed frequency. When the file system is written to infrequently (like in the test) then background cleaning erases all garbage between successive writes. Increasing the background skip factor (currently 10) would make the cleaning run less frequently and thus produce less wear, so maybe this should be a configurable parameter.

I would like to hear your comments. Please kindly forgive me (and enlighten me) if I didn't understand the logic behind the code properly. I pay a lot of attention to these details because I'm intending to use yaffs in an application where keeping flash wear low is crucial.

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