OSDev.org

It's not good to synchronize the FAT table on disk, per FILE read or write.

blackoil wrote:It's not good to synchronize the FAT table on disk, per FILE read or write.

Firstly I don't think this is a question. And secondly why would you want to sync the FAT table? What are you going to sync it to?

System123 wrote:

blackoil wrote:It's not good to synchronize the FAT table on disk, per FILE read or write.

Firstly I don't think this is a question. And secondly why would you want to sync the FAT table? What are you going to sync it to?

the other copy of the FAT table perhaps?

I copy the FAT to ram when startup, if read/write file, the FAT updates in ram.
It has to write it back to disk.

blackoil wrote:I copy the FAT to ram when startup, if read/write file, the FAT updates in ram.
It has to write it back to disk.

The FAT never changes when you read. You will only need to change FAT on a write. But if you are writing to the disk you shouldn't be writting the FAT entries to RAM, this will cause trouble later.

You also need to update FAT2 table on the disk as it is a back up.

yes, I know a read doesn't change the FAT.
If write back the FAT per writefile, it's very slow for only 5gb partition.
If I cache the FAT table, it's fast

FileOpen
{
if no files opened before, read the FAT to ram
open the file
}

FileClose
{
close the file
if no files left open, write back the FAT to disk
}

does this works best? if no power loss when running.

blackoil wrote:FileOpen
{
if no files opened before, read the FAT to ram
open the file
}

FileClose
{
close the file
if no files left open, write back the FAT to disk
}

does this works best? if no power loss when running.

The first part will work fine. The second part is a problem. Because what if the system crashes, but you still had files open. The 2nd one could work if you sync the FAT on any change. Here is a fast way to do it.

Keep 2 arrays of the 10 bytes, (the last 5 in the FAT, and the first 5 after the last FAT entry. 1 for RAM and 1 for Disk). Then after x delay check that those bytes are the same. If they are the FAT is fine, if they not then copy the FAT.

You could also just copy the FAT on every successful write to the drive. This is probably the easier and quicker route.

There's of course only a need for updating the FAT if the write causes the file to expand, in which case you need to allocate new blocks for the file. Typically, allocating blocks on a disk and writing a file are separate tasks, executed by separate parts of the VFS/driver. Also, you only need to write the FAT once on a single data write, as you know on forehand how much the file is going to expand, so you can reserve room and update the FAT only once. Next, you write the data. Anyway, you need update the directory entry as well, writing causing file expansion is just slow, live with it.


JAL

In my OS any write is done in ram, than written to disk ( as in no waiting ), But mine is designed a a single-task games console OS.
One thing i would add is, i only write to the first fat on my OS.

Dex wrote:One thing i would add is, i only write to the first fat on my OS.

Which means that the disk is unreadable by any other OS? In that case, I'd go for my own file system format.


JAL

The idea of a doubled FAT is to have some redundancy.

IIRC In real life OSes do not normally check the second FAT (and therefore do not notice its off)

One of the advantages to a second FAT comes if the first FAT becomes corrupted (somehow) or the disk sectors for the first FAT become unreadable. Recovery utilities could (and this is only speculation) then use the second FAT to create a replacement.

Also, you (should) use the BPB_NumFATs variable rather than assuming there's two (or less) FATs, if you do decide to write to all the FATs

pcmattman wrote:One of the advantages to a second FAT comes if the first FAT becomes corrupted (somehow) or the disk sectors for the first FAT become unreadable. Recovery utilities could (and this is only speculation) then use the second FAT to create a replacement.

The problem is, the second FAT could be corrupted instead, and reverting to it leads to disaster (it happened to me a long time ago). There's no checksum over the FAT tables, so software is only able to detect whether there's differences between the versions, not true corruption (well, obviously some corruption like double allocation etc.).

Also, you (should) use the BPB_NumFATs variable rather than assuming there's two (or less) FATs, if you do decide to write to all the FATs ;)

Iirc, Microsoft in its FAT document says that only a value of 2 is allowed, ever. I'm too lazy to check however.


JAL

jal wrote: Iirc, Microsoft in its FAT document says that only a value of 2 is allowed, ever. I'm too lazy to check however.
JAL

ya, the new version of the FAT docs changed that... (the original specification made no such requirement)

actually, any number of FAT tables can be used, however the new revision require only 2 to be a valid value, for compatibility with improperly written software (back in the old days, it was quite common for programs to write their own FAT drivers rather than use DOSs, and they often assumed things they shouldnt have)

the specification also mentions that all MS OSs can properly handle disks with any number of FAT tables

for maximum compatibility, you should not expect it to be 2 for existing disks, but should only create disks with exactly 2

blackoil wrote:I copy the FAT to ram when startup, if read/write file, the FAT updates in ram.
It has to write it back to disk.

For this you want a write through buffer. Reads are fetched from the buffer, while writes update the buffer and the disk, in this way the disk is always in sync. There is little to be gained from delaying the write to disk and much to lose. When writing kernel level disk I/O routines, keep in mind that the power could fail at any millisecond. This is why journaling file systems are so nifty.