Re: [Yaffs] Re: yaffs robustness against power failures -->t…

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: yaffs
CC: wookey
Old-Topics: [Yaffs] Re: yaffs robustness against power failures
Subject: Re: [Yaffs] Re: yaffs robustness against power failures -->transactioned writes
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