Lpc2000

Gus wrote:
> Hi,
> 
> Maybe it would be better for the file system structures but the data 
> that was about to go on the media when the power failure happened is 
> lost!

It applies for both - whenever the system comes up, the filesystem state 
(data and structures) is at it was when the last successful commit() 
call completed. Anything you write before a commit() may be lost unless 
you commit() it. If efficiency isn't such a problem, you can do a 
commit() after every write. Sure, if power fails during or before the 
commit you may lose stuff, but what you gain over systems like FAT is 
that you don't run the risk of a power failure during write causing the 
existing data that was being overwritten from being lost - you don't 
need all this "backup FAT" stuff to repair broken filesystems.

The techniques used for this are quite fascinating - I've done some work 
on them myself. To cut a long story short, if you can organise the 
entire filesystem as a tree of blocks, with each block containing some 
mix of data and pointers to child blocks and its parent block (eg, a 
B-Tree, or something like that) you can handle updates by just writing 
new copies of the modified data blocks. This means that the address of 
the most recent versions of those blocks has changed, so you need to 
also "modify" the parent blocks by writing newly updated copies of them 
out, too, all the way up the tree until you finally get a new root pointer.

Now, the current root pointer is stored TWICE on the filesystem, once at 
each end or similar. Update one, then the other. Your commit has now 
finished.

When the system starts up, read the root pointer from both copies; if 
they differ, the system died between updating the two, so use the one 
with the highest timestamp. If they don't differ, then that's your root.

Voila!

Now all you need is a way of managing free space that clears up all 
those blocks that have been superseded by more recent copies - that's 
where the fun part is.

There are other techniques, too, like journalling.

> The idea of ALFAT chip is that you can EASILY share data between 
> systems and your PC and the only choice is FAT as it is supported by 
> almost any OS

Quite, I wouldn't argue with that. There's nothing quite as universal as 
FAT! Apart from death and taxes... :-) Strange file system structures 
may be very nice, but they're still not widely deployed at all... 
despite the foundations of them dating back to about the 60s or so! But 
I'm not attacking your choice of FAT for interoperability, not one bit, 
and sorry if it seemed otherwise!

> 
> Thanks,
> 
> Gus
> 

ABS

-- 
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/categories/alaric/