On 06/20/2013 09:42 AM, James Kehl wrote: > Suggestions: > 1. Dedicate a partition to your power-off storage. This avoids the "file system might be full" issue, and you can guarantee an upper bound on the garbage collection time. Doesn't need to be a big partition - for 8k data, 32k should be enough (most recent copy, backup copy, file headers, checksum block). > > 2. Do online garbage collection, instead of leaving it until write time. > > 3. Do periodic backups regularly, *without* waiting shutdown. It's better to lose e.g. 5-10 seconds of data than weeks, months or years. Of course, your Flash wear rate goes up, and you have to worry about wear levelling (and that probably rules out the small partition), but your worst-case "can't shutdown" situation (e.g. running out of shutdown time, but also hardware resets or software crashes) can be tuned to avoid upsetting your customers too much. > > In my product, I actually flush all my data to Yaffs every second (with a bit of delta compression and transaction logging, to keep the write rate <1 page/sec). Not having to worry about clean shutdowns at all is quite nice! > > J > Thanks James, for your super fast response. 1) I think it should be at least a few physical erase blocks of the NAND (128k in our case), and if we have it even larger we can probably avoid the 'aggressive' wear leveling mode completely? 2) Under Linux there is a background task for garbage collection. Do I need to turn it off? It probably makes it less predictable. Can this easily be achieved? What do you mean by 'online' GC (while power is still good)? How do I force the GC under Linux? 3) In our application it's not a matter of loosing weeks, but we are dependent on these 'right before powercut' data, so flushing probably won't help. We were thinking of extending yaffs2 by an fallocate() system call, that reserves blocks to the given extent, just to be sure they sit there ready for writing, independent of the garbage collection. I'm just not deep enough into yaffs2 to dig into this right away. Helmut -- Scanned by MailScanner.