Embedded RTOS - features poll

I think I misinterpreted your first statement. I missed the fact that you did say that you had to write _one_ FAT table when you format the card. However, on a large card, writing 16MBytes of FAT could take quite a while.

I was thinking that, if the empty disk had all sectors filled with 0x00, you might not have to write all the FAT sectors, since 0x00000000 is the FAT marker for an unused cluster.

Mark Borgerson

Reply to
Mark Borgerson
Loading thread data ...

Mark Borgerson expounded in news: snipped-for-privacy@news.eternal- september.org:

Writing 32 sectors isn't huge (32k/512 bytes each). Comparing it to a file write, if you use 8 sectors per cluster, it is only two clusters worth of writing.

That doesn't work on a couple of levels. The first FAT entry is supposed to include the media type byte, though I doubt many implementations pay any attention to it there.

Also if you use FAT32, your root directory is located in a cluster. So at least one cluster has to be pre-allocated.

But those things could be localized to the first FAT sector.

Warren

Reply to
Warren

I don't understand this.

IIRC, a cluster can be no more than 32KB for Windows and FAT32.

A 32GB volume then needs about 1,024,000 entries of four bytes each. or 4MBytes for the minimum size FAT. I can't get from there to your 32 sectors.

So, could you just write the first FAT entry and leave the rest of the sectors as 0x00s?

Mark Borgerson

Reply to
Mark Borgerson

Mark Borgerson expounded in news: snipped-for-privacy@news.eternal-september.org:

See:

formatting link

"Sectors Per Cluster: This is the number of sectors per cluster. The allowed values are: 1, 2, 4, 8, 16, 32 or 128. But de-facto is that most combinations of 'BytesPerCluster' * 'SectorsPerCluster' which gives a total value over 32 Kb per cluster, are not supported on many system[s]."

Note: in the above, I believe the author meant 'BytesPerSector', rather than 'BytesPerCluster'. Otherwise his math is meaningless.

Given his 1999 copyright date:

his "level of support statement" may not be accurate anymore (no mention of any O/S later than WinNT or Win98 is mentioned).

From your "16MBytes of FAT" -

16MB / 512 => 32 sectors.

Yes (assuming you meant that the remaining sectors are zeroed _and_ written out).

The only caveat would be if you tested for and found bad sectors. Then you'd also need to mark those clusters containing bad sectors as bad (unavailable) - FFF7 (FAT16).

Warren

Reply to
Warren

Warren expounded in news:Xns9E018EE612954WarrensBlatherings@85.214.73.210:

Actually, there was one more thing I forgot about:

The last part of the FAT will likely need FAT entries indicating that the last n clusters are unavailable. This happens when your FAT table has more entries in it than, available clusters to manage.

Otherwise, instead of running out of space, you'll get I/O errors when the FS attempts to use non-existing clusters (unusable space will be allocated from the FAT).

Warren

Reply to
Warren

I think the author is also mixing up bits and bytes. 32KB != 32Kb.

How do you divide (16 x 1024 x 1024) by 512 and get 32?

When I do that division I get 32768 sectors.

I don't think you even use FAT16 on a 32GB volume with a single partition.

Mark Borgerson

Reply to
Mark Borgerson

Mark Borgerson expounded in news: snipped-for-privacy@news.eternal-september.org:

My bad. I was thinking 32k.

In any case, formatting a FAT is at least two orders of magnitude less than formatting the whole drive/partition. Look at the ratios involved (assuming FAT32):

128 cluster entries in one FAT sector,

vs

8 sectors per cluster (for example).

This is 1 sector vs 128 * 8 sectors, i.e. a ratio of 1 : 1024 !

It's actually worse than that because if you do the whole drive you do FAT + clusters:

1 : 1024 + 1

So formatting a FAT takes 1/1025th the time it takes to do the whole drive. Very significant, that.

Even if you dumbed it down to 1 sector per cluster which nobody does since FAT12 floppies, you're looking at a ratio of 1 : 128+1.

The procedure is necessary and the same for both FAT16 and FAT32.

formatting link

"Windows XP supports the creation of primary partitions and logical drives of up to 4 gigabytes (GB) using the FAT16 file system. The maximum cluster size is 64K."

So you can see that the 32K limit was extended to 64K in XP. And yes, FAT16 has its limits, but so what? Use FAT32. MS says "FAT32 supports drives up to 2 terabytes in size.". FAT32 only changes a few things (from FAT16) and is a simple upgrade to support (it was trivial for my own software to support both).

As far as long file names go, you don't have to support them in your AVR code, unless you really really want to. I don't bother.

Warren

Reply to
Warren

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.