Re: [Yaffs] Using YAFFS to store data right before powercut

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Helmut Raiger
Date:  
To: yaffs@lists.aleph1.co.uk
Subject: Re: [Yaffs] Using YAFFS to store data right before powercut
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.