FAT32 Cluster Sizes

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I am doing a project with an SD card and FAT32. The largest cluster size I can deal with is 4K. I am trying to find where the sizes are defined. I looked at a 16GB SDHC (UHS 1) and it will do 4K clusters, and a 32GB (UHS1) card bottoms at 8K. My question is this: Are these numbers written down somewhere? I need to tell my customers which cards will work.

 

Thanks!

 

-TimR

Tim Ressel
Portland, OR
timr@earthling.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Last Edited: Sun. Dec 13, 2015 - 01:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As Joey says fatgen103 dictates this. You can override the default when you format the card but I wouldn't hard code limits into your FAT support forcing the user to specially format cards. Why can't your code handle clusters greater than 4K anyway? Modern card sizes are 1GB to 128GB. These are bound to have at least 32K clusters,  perhaps larger even. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

As Joey says fatgen103 dictates this. You can override the default when you format the card but I wouldn't hard code limits into your FAT support forcing the user to specially format cards. Why can't your code handle clusters greater than 4K anyway? Modern card sizes are 1GB to 128GB. These are bound to have at least 32K clusters,  perhaps larger even. 

I need enough RAM to buffer 2 clusters. Given the RAM available that means 4K clusters. Unless it is possible to perform a read of less than a full cluster?

 

--TimR

Tim Ressel
Portland, OR
timr@earthling.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The minimum is a sector - 512 bytes. The concept of the cluster is to minimise the fat table size. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unless it is possible to perform a read of less than a full cluster?

Of course it is! The granular unit in most storage systems is one "sector", not an entire "allocation unit". Apart from very modern hard drives (4096 byte sectors) sectors have always been 512 bytes. When you use FatFs for example it only ever holds one 512 bytes sector in RAM and its entire RAm requirement is only just something like 570 bytes. In fact there is even a cut-down version of Fatfs called "Petit" that doesn't even need to cache an entire sector. When it needs to read bytes 37 to 63 in a particular sector is does 36 dummy reads of the preceding bytes and then reads bytes 37 to 63 one at a time. It has a total RAM requirement of something like 40 bytes and yet it can read/write FAT16/FAT32. True, it's inefficient and I guess there's an argument to say that a FAT reading system that only holds 512 bytes at a time might benefit from some "caching" too (even if it were only to hold 2 sectors, 1024 bytes so it could handle "spills" at the end of one sector better) but 512 bytes is very practical and it makes no assumptions about the size of the allocation units.

 

It sounds like you may have written your own FAT software from scratch - is there some reason you didn't just port FatFs to your target?

Last Edited: Mon. Dec 14, 2015 - 10:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, no .. I am not writing my own FS. I may be crazy, but I'm not insane. I'll be using FatFS or similar for my file system needs.

 

I'll be allocating 4K buffers for each of the 8 audio channels. I guess I can do less, but the proc has tons of ram so why not? With 512B reads I can keep the buffers nice and full.

 

Thanks so much for your help!

 

--TimR

Tim Ressel
Portland, OR
timr@earthling.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But you appear to be mixing two levels of the software design then - apps and drivers. FatFs is a driver - it handles the dataflow to the storage media in sectors and allocation units. At the level you interact with such a thing you aren't aware of any such implementation detail. Just like <stdio.h> filing in DOS you simple fopen(), fread(), fclose() files and read as much or as little data as you like at this level. It has nothing to do with the implementation details in the low level filing system. It's like if you were to fopen() and then fwrite() a file on your PC right now. You might write 3 bytes or 3 thousand million bytes - the way you do it would be identical - you don't even know what storage device the OS might be storing it on - HDD, SSD, SD/MMC. USB-MSD, (RAM even) etc. You certainly don't concern yourself with details like the AU/cluster or sector sizes on such things - the OS/driver hides that all from you.