[Yaffs] Re: yaffs robustness against power failures -->transactioned writes

[Charles Manning]

Sorry I missed the second part of this:

> OTOH, if there's enough space to hold both the old and the new versions,
> will the power pailure always be handled by the filesystem in such a way
> that retains the integrity of the file being written (i. e. either the
> old or the new version). 

The problemn with this approach is that it can only give you limited safety. 
To ensure safety, you'd have to limit the maximum usage of the flash to 50%.

Consider a 50MB file system containing a single 49MB file. In theory you could 
rewrite that file in a single call:

  write(h,buffer,49*megabytes);

To be able to roll back the fs we'd need to have 49MB free to store the 
overlap, which means we'd need a 100MB NAND to store a 50MB file system.

Of course one could go for a compromised "best effort" approach where you 
have, say 5MB of backup and use that when you can, but don't do it if the 
writes are too big (or immediately fail writes that are bigger than the 
overlap).

It would be possible to add "best effort" transaction rollback to YAFFS2 (not 
to YAFFS1) by doing some interesting things with garbage collection.

Currently YAFFS2 does all file writes and other write activities on a "per 
chunk" basis. If a chunk is being overwritten, then as soon as we write the 
new one the old one becomes garbage. This means we can end up freeing and 
reusing a particular chunk of NAND within the same write. This would 
obviously break the ability to rollback. We could constrain the garbage 
collector to not collect blocks that contain these recently released chunks, 
then write some sort of post-transaction marker to show that the new stuff 
has been accepted.

Doing the above would not be very difficult, but it would have some downsides:
1) It would only be a "best effort" solution, or alternatively might limit 
writes to free clean space only.
2) Constraining the garbagecollector means that we don't always get the best 
garbage collection choices and so performance might suffer a bit.

I'm pretty confident that the results would still be faster than other 
embedded-level transactioning fs that I've seen.

-- Charles