Embedded FAT16 -> FAT copy handling

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

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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.

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

Pour me répondre :

"David Brown" a écrit dans le message de news: d8ruqi$93r$ snipped-for-privacy@news.netpower.no...

inconsistencies.

Ok thank u for all those precisions. I'll try maintain my FAT copy valid .

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).

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

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

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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

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.

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.

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

It's true, honest :-)

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.

"Yvan BOURNE" a écrit dans le message de news:d8tvp5$9e9$ snipped-for-privacy@news.tiscali.fr...

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..

This switch toggle AFTER the contacts are removed from the card....

--

--- Yvan

Pour me répondre :

"Fred*" a écrit dans le message de news:

42b3c56d$0$20252$ snipped-for-privacy@news.wanadoo.fr...