OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Apr 19, 2024 5:01 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: Why not FAT file systems?
PostPosted: Wed Oct 14, 2020 10:36 am 
Offline
Member
Member
User avatar

Joined: Tue Sep 15, 2020 8:07 am
Posts: 264
Location: London, UK
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.

_________________
CuriOS: A single address space GUI based operating system built upon a fairly pure Microkernel/Nanokernel. Download latest bootable x86 Disk Image: https://github.com/h5n1xp/CuriOS/blob/main/disk.img.zip
Discord:https://discord.gg/zn2vV2Su


Top
 Profile  
 
 Post subject: Re: Why not FAT file systems?
PostPosted: Wed Oct 14, 2020 1:11 pm 
Offline
Member
Member

Joined: Tue Feb 18, 2020 3:29 pm
Posts: 1071
If you dump the values of the BPB via your OS, what does it say for sectors per cluster?

_________________
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg


Top
 Profile  
 
 Post subject: Re: Why not FAT file systems?
PostPosted: Wed Oct 14, 2020 2:02 pm 
Offline
Member
Member
User avatar

Joined: Fri Mar 01, 2019 3:50 pm
Posts: 39
Location: France
bloodline wrote:
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.

bloodline wrote:
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 :P

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


Top
 Profile  
 
 Post subject: Re: Why not FAT file systems?
PostPosted: Wed Oct 14, 2020 2:16 pm 
Offline
Member
Member
User avatar

Joined: Tue Sep 15, 2020 8:07 am
Posts: 264
Location: London, UK
nexos wrote:
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.

crosssans wrote:
bloodline wrote:
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.

bloodline wrote:
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 :P

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?

_________________
CuriOS: A single address space GUI based operating system built upon a fairly pure Microkernel/Nanokernel. Download latest bootable x86 Disk Image: https://github.com/h5n1xp/CuriOS/blob/main/disk.img.zip
Discord:https://discord.gg/zn2vV2Su


Top
 Profile  
 
 Post subject: Re: Why not FAT file systems?
PostPosted: Wed Oct 14, 2020 4:02 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5137
For FAT12 and FAT16, the data area starts after the root directory. That might be why your calculations are getting you the wrong sectors.


Top
 Profile  
 
 Post subject: Re: Why not FAT file systems?
PostPosted: Wed Oct 14, 2020 4:33 pm 
Offline
Member
Member
User avatar

Joined: Tue Sep 15, 2020 8:07 am
Posts: 264
Location: London, UK
Octocontrabass wrote:
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. #-o

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

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

_________________
CuriOS: A single address space GUI based operating system built upon a fairly pure Microkernel/Nanokernel. Download latest bootable x86 Disk Image: https://github.com/h5n1xp/CuriOS/blob/main/disk.img.zip
Discord:https://discord.gg/zn2vV2Su


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 6 hours


Who is online

Users browsing this forum: SemrushBot [Bot] and 155 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group