Embedded FAT16 -> FAT copy handling

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all,

I've successfully implemented a FAT16 on my CF, but i don't know how to
deal with the fat copy !

When modidying the original FAT, should i *REALLY* have to modify the
2nd FAT for each writes, or operating systems can handle *some* errors
in the 2nd fat ?

Thank you.


Re: Embedded FAT16 -> FAT copy handling
Quoted text here. Click to load it

I update the second fat in order to avoid problems and remain as
compatible as I can. It's not really such a big deal in that I simply
write the first fat's sector in question, then add the distance offset
to the second fat and issue a second write.

I found that maintaining a two fat secrors read cache gives the
highest performance gain without vasting too much resources. There one
fat is maintained as a general purpose fat read sector cache where as
the other "hovers" over the fat area from where I allocate new
clusters if the need ariese. That's because it turned out that in
"real live (tm)" finding an empty cluster is the most time consuming
operation.

If you want to update only one fat, it's perfectly valid to format
your media so as it has only ONE fat and if your fat code is worth
it's money :-) then it should already deal propperly with a media
formated ths way. Windows & DOS incarnations will treat such a CF the
right way - might not be the case with other platforms/devices though.

The drawback from above aproach is that all CF's you buy will be
formatted using two fats, so you would have to re-format them first.
You could do this in your initializing code asuming that a two fat cf
is "new" hence you reformat. Wether this is an option or not of course
depends on the kind of application you use.

Microsoft is having a PDF online on their site which clearly points
out all compatibility issues that you should take care off.

HTH

Markus

Re: Embedded FAT16 -> FAT copy handling

Quoted text here. Click to load it

You have essentially two choices:

1) don't use a 2nd FAT, and risk some other users being confused by that

2) use a 2nd FAT, and maintain it correctly

A 2nd FAT copy that's not kept up-to-date is not going to anyone any good,
so you might as well drop it completely.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Embedded FAT16 -> FAT copy handling
Quoted text here. Click to load it

As far as I remember, the FAT format allows for 1, 2, or 3 copies of the
FAT.  DOS and Windows use two copies, and which they always update when
writing.  However, they only ever read the first copy - the second copy
is ignored, so they will not notice if it is not updated.  It may be
that that will compare the two FATs during a chkdsk, but even then they
treat the first copy as correct (after all, without any checksums or
timestamps, there is no way of identifying the correct version).  Other
implementations of FAT might be more sophisticated and spot inconsistencies.

Re: Embedded FAT16 -> FAT copy handling
Hi,
I have a question about FAT (on SD card) :
- if I leave the card from its connector while the processor is writing FAT,
what is the result ?
   - the FAT is not updated and thee last values are saved,
   - the FAT is partially written, and I will not be able to read it in the
future...

Regards,

--
---
Yvan
http://www.ybdesign.fr

We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded FAT16 -> FAT copy handling
Quoted text here. Click to load it

Quite simply, don't do it.  FAT is not journaled in any way, so a
half-done write or an error in a critical area (such as the FAT,
especially the first FAT), will leave you with some or all of your data
missing, and your file structure corrupt.  If you want to have something
that can survive unexpected disconnects, use a journaled file system
like jffs2 (and even then, do your best to avoid disconnects).

Re: Embedded FAT16 -> FAT copy handling
Quoted text here. Click to load it

Just do what most, if not all digital camera (and floppy drive)
manufacturer did: put a "writing data" light on the case, next to the
card slot, and put a *huge* warning in the manual telling people to
keep their dirty fingers off that card as long as the light is on.

There's no way you can guarantee anything close to safe operation of
a FAT file system if people are allowed to remove

Quoted text here. Click to load it

You can't know, but you can _tell_ them

1) don't do it
2) I'm serious, don't!
3) if you do don't respect the above, good luck ever getting those data back

Quoted text here. Click to load it

That's the filesystem-in-a-filesystem approach.  It won't help you at
all, because the actual contents of that CF card will be just as completely
unreadable as they would have been if you had used a completely different
filesystem instead of FAT from the get-go.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Embedded FAT16 -> FAT copy handling
Quoted text here. Click to load it

That's not quite true these days. SanDisk, for instance, fully document
their write-abort handling procedure. A write command will either fully
complete or else be rolled-back if it was interrupted before completion.

In other words, solid-state CF cards provide a write transaction layer. The
media is never unreadable; you either get the old data before the
interrupted write or the new data following successful completion of the
write.



Re: Embedded FAT16 -> FAT copy handling

Quoted text here. Click to load it

And that handling covers the card being bodily ripped out of the slot
in the middle of action, cutting the power supply and everything?  I
find that a bit hard to believe.

Quoted text here. Click to load it

That won't do you much good unless the card itself implements the file
system --- which I'm reasonably sure a CF card doesn't.  A FAT file
system write operation contains of at least roughly 4 sector-write
operations (the file itself, the directory entry, and the 2 FATs).
Disturb this sequence, and you've got a corrupted filesystem.  Not
quite as bad as overwriting a FAT with utter garbage because of a
power failure in mid-stride, granted, but still corrupted.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Embedded FAT16 -> FAT copy handling
Quoted text here. Click to load it

It's true, honest :-)

Quoted text here. Click to load it

Absolutely, but with a little care, you can acheive a rugged storage system
on top of FAT:

1) Damage limitation
The worst case damage can be limited to one file and, by pre-allocating
space in safely-sized chunks, the nature of the damage does not invalidate
the entire file-system.

2) Damage recovery
The afore mentioned damage can be detected and the offending file is then
deleted.

These measures are not a problem in many embedded systems where you have one
file open for writing at any given time and the approximate size and usage
pattern of the file is well known at design time.



Re: Embedded FAT16 -> FAT copy handling
On Fri, 17 Jun 2005 09:57:15 +0200, "Yvan BOURNE"

Quoted text here. Click to load it

Put a "Write" warning indicator on, and put the card behind a flap
with a sensor. When the flap is opened stop writing your data. The
user then waits until the write indicator is off, and then removes the
card.

Regards
  Anton Erasmus


Re: Embedded FAT16 -> FAT copy handling

Quoted text here. Click to load it
are
FAT,

there are several SD connector with a "card present switch", so you could
use this switch to detect the presence of the card and set an alarm if the
user remove the card before wrinting completion..



Re: Embedded FAT16 -> FAT copy handling
This switch toggle AFTER the contacts are removed from the card....

--
---
Yvan
http://www.ybdesign.fr

We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded FAT16 -> FAT copy handling
Ok thank u for all those precisions. I'll try maintain my FAT copy
valid .


Site Timeline