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
> -----Original Message-----
> From: yaffs-bounces@lists.aleph1.co.uk [mailto:yaffs-
> bounces@lists.aleph1.co.uk] On Behalf Of Helmut Raiger
> Sent: Thursday, 20 June 2013 5:12 PM
> To: yaffs@lists.aleph1.co.uk
> Subject: [Yaffs] Using YAFFS to store data right before powercut
>
> Hi,
>
> we try the following:
>
> 1) setup some data in an 8kByte block in RAM
> 2) frequently modify this data during normal operation
> 3) on a power fail signal write the block to a file on a NAND flash
> partition
> 4) recover from the written data after the power cut
>
> The time between power failure notification and the uP-reset is
> guaranteed by hardware
> and is about 20ms.
>
> Simply fsync()ing the file in case of a power cut does not seem
> reliable, for
> - the file system might be full
> - the garbage collector might run to free dirty LEBs and erase the
> corresponding PEBs
> The latter overstretching our timing requirements.
>
> This is on an embedded system (i.mx31, arm1136@532MHz) running Linux
> 3.something
> (we are quite flexible in adapting new kernel versions), currently
> testing on 3.0.45.
>
> Could someone hint the course to follow for this szenario?
>
> Any pointers appreciated,
> Helmut
> PS: I've already asked the very same question on linux-mtd (more
> specifically about UBIFS) to no avail. I thought YAFFS might be more
> suitable due to its more predictable garbage collector.
>
>
> --
> Scanned by MailScanner.
>
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
(text/plain)