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

-- 

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
<http://www.hasar.com>Información legal y política de confidencialidad: 
www.grupohasar.com/disclaimer <http://www.grupohasar.com/disclaimer>