James Sparenberg wrote: > I would think the reference here is to lifetime of cell X of the SD card. > Meaning here that each "block" (or whatever the correct term is) has a set # > of wrtie/read events. JFFS from what I'm reading understands this and as > such move journal information around just enough to even out this wear. > > My understanding is that jffs also takes steps to minimize the # of times and > amount of reads/writes it does. ext3 however doesn't and it's hitting the > HDD a lot more often. One of the reasons I'm not ext3's best fan. jffs runs directly on raw NAND flash so it must do such things. SD cards however are normal block devices and my understanding is that they do same or similar wear levelling when writing blocks. So even if you write same (logical) block on sd card the write goes somewhere else with each write. I don't work for flash card manufacturer so I am not 100% sure on this but I guess there is no other sane way how to do it internally in the flash controller on the card. You need to handle same problems there (much bigger physical block in NAND chip than logical, pre-erasing blocks what data is written, remapping bad blocks, ...) like jffs2 I think that flash cards are like harddisks nowadays. You no longer care about physical geometry and bad blocks on current hard disks, all is done transparently by disk controller and you simply don't know and can't even guess where on the disk specific block is really stored. > > Ext2 and FAT don't do anything special. They also don't do anything over and > over again in the same spot. I think FAT table is the spot which is written over and over againg in most devices using flash cards. Write caching is not common for removable media so it may be even updated after doing every write operation to file. And if manufacturers are giving long/lifetime warranty despite this common usage I wouldn't bother with ext2 or ext3 which is typically mounted with write caching. Frantisek
