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 -- 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