Why not FAT file systems?

[bloodline]

Ok weird question... But what does the "sectors per cluster" field in the volume boot record actually tell me?

I have an 80meg HD image I'm using for my kernel. I formatted with FAT32, so that it has a single partition, and 1 sector per cluster, 512 bytes per sector, and this is working well, nice and simple.

Have now made a new HD 80Meg image for use with GRUB2, and MacOS Disk utility automatically formatted it FAT16... I decided to leave it as FAT16 to test my FAT FS driver.

But this has a value of 4 in the Sectors per cluster field, now my cluster to LBA conversion function seems wrong as I am calculating 2048 bytes per cluster (512 * 4), but when I look at the HD image file in a Hex viewer, it's clear there are 8192 bytes per cluster (16 sectors per cluster!)... I'm hugely confused by this.

[nexos]

If you dump the values of the BPB via your OS, what does it say for sectors per cluster?

[crosssans]

Ok weird question... But what does the "sectors per cluster" field in the volume boot record actually tell me?

The "sectors per cluster" indicates the number of logical sectors (and not physical, as some tools may actually specify something higher than the physical number of bytes per sector on the media, see below!) used by one cluster on the data portion of the FAT filesystem.

Have now made a new HD 80Meg image for use with GRUB2, and MacOS Disk utility automatically formatted it FAT16... I decided to leave it as FAT16 to test my FAT FS driver. But this has a value of 4 in the Sectors per cluster field, now my cluster to LBA conversion function seems wrong as I am calculating 2048 bytes per cluster (512 * 4), but when I look at the HD image file in a Hex viewer, it's clear there are 8192 bytes per cluster (16 sectors per cluster!)... I'm hugely confused by this.

And that's where the "Bytes per logical sector" field comes into play: I guess that your disk utility probably set this to 2048 bytes instead of 512 - and that's where your cluster to LBA conversion fails, because you're assuming that a disk will always have logical sectors that are 512 bytes

There is a really good article on Wikipedia that has a section where all fields of the FAT's BPB are described: https://en.wikipedia.org/wiki/Design_of ... eter_Block
At the bottom of these tables, there are two formulas that will help you fix your conversion function

[bloodline]

If you dump the values of the BPB via your OS, what does it say for sectors per cluster?

The BPB has a value of 512 for the bytes per sector field.

Ok weird question... But what does the "sectors per cluster" field in the volume boot record actually tell me?

The "sectors per cluster" indicates the number of logical sectors (and not physical, as some tools may actually specify something higher than the physical number of bytes per sector on the media, see below!) used by one cluster on the data portion of the FAT filesystem.

Have now made a new HD 80Meg image for use with GRUB2, and MacOS Disk utility automatically formatted it FAT16... I decided to leave it as FAT16 to test my FAT FS driver. But this has a value of 4 in the Sectors per cluster field, now my cluster to LBA conversion function seems wrong as I am calculating 2048 bytes per cluster (512 * 4), but when I look at the HD image file in a Hex viewer, it's clear there are 8192 bytes per cluster (16 sectors per cluster!)... I'm hugely confused by this.

And that's where the "Bytes per logical sector" field comes into play: I guess that your disk utility probably set this to 2048 bytes instead of 512 - and that's where your cluster to LBA conversion fails, because you're assuming that a disk will always have logical sectors that are 512 bytes

There is a really good article on Wikipedia that has a section where all fields of the FAT's BPB are described: https://en.wikipedia.org/wiki/Design_of ... eter_Block
At the bottom of these tables, there are two formulas that will help you fix your conversion function

Yes, haven't hard coded any values, the 512 comes directly from the BPB... thanks for the link though, I was trying to find that at lunch today! I'll have a play before bed.

Am I correct that with FAT16 the Root occupies the second cluster of the data area? or does the data area start after the root directory?

[Octocontrabass]

For FAT12 and FAT16, the data area starts after the root directory. That might be why your calculations are getting you the wrong sectors.

[bloodline]

For FAT12 and FAT16, the data area starts after the root directory. That might be why your calculations are getting you the wrong sectors.

Yes, that was the problem.

So I now need two separate root processing paths...

-edit-
But I now have both FAT32 and FAT16 file systems working!

Again, thanks to all who made suggestions.
I know my questions can be naive, but in less than a month, I've gone from an idea to a running, multitasking OS, this is an extremely helpful community!