fdisk created fat32 partition, which type 0b or 0c?
 

I have never been able to find any accurate information on this.

Let's say I have a 100GB hard drive (/dev/sda) and need to create a 20GB partition (/dev/sda1) to be used as Windows C:.

What partition type would be needed for this (0x0b or 0x0c) and how do you determine which to use?

Is is based on bios access method (lba or chs), size of partition, or location of partition? Maybe a little of each?

I'm guessing it has something to do with the disk geometry/filesystem limitations over the years. (528M,4G,8.4G,128G)

Fat 32 Fat stands as you know fore File Allocation Table It is the pointers of all you,re files
In the old days when you delete a file you only remove the pointer out of the fat so until it is overwritten
you can recover it
History begins with FAT 8 and Fat 16
It has some thing to do with the address the processor can handle and the amount of bites
When storage capacity are growing the heads and the amount off disk in the hd are growing
It was I think windows Me was the last one how use this type off file system
But still any OS needs to know where he can find the files
If you have a HD of 100 GB unformatted it is less 100 GB when it is formatted

Hope it use full information

all the best

Go for 0x0c unless your hardware is really old (last century)
Modern BIOSs all use LBA.

hey onedingo,

is this a trick question? tredegar gave the answer already but in case this is no trick question and you really want to know i am trying to answer it a bit more detailed.

it depends on your bios and it's block adressing method: lba or chs. if chs 0x0b else 0x0c.

a little bit of each. 0x0b is a FAT32 primary partition. access method chs, size of partition must be <= 2047 GB. location: dunno if it must be the first partion but it must be primary as said before. 0x0c is FAT32 using lba. rest is the same...

hope this helps, vadkutya

Something still isn't right then.

Using gparted (Under SysRescueCD), I created a FAT32 partition and this is what it gives:

It went with 0x0b even though the drive must(?) be using LBA as:

1. I have it set that way in the BIOS.
2. Drive size is greater than 7.8 GiB. (Extended BIOS CHS Limit)
3. dmesg has this tasty bit:
ata1.01: ATA-5: WDC WD400BB-00AUA1, 18.20D18, max UDMA/100
ata1.01: 78165360 sectors, multi 16: LBA

While this may not be an issue for Linux as it does not care about CHS, it may be an issue for Windows.

Possible bug in gparted or is 0x0b still used for (small?) partitions on LBA drives?

b is indeed FAT32 without LBA. if the partition is still free convert the filetype with fdisk:
now you have FAT32 LBA.

vadkutya

@vadkutya
I understand how to change the type, but that may create "issues".

Here is what I just did:

1. Booted SysRescueCD
2. As root, dd if=/dev/zero of=/dev/sdb bs=512 count=1
3. Use gparted to create msdos partition layout and create 1 primary partition formatted as FAT32

Resulting in:
So either my understanding is off or there is a bug in gparted.

hey onedingo,

i never used gparted so i don't know if there's an option you are probably missing or so. also, i don't understand why fdisk might create "issues". but another way would be using mkfs.msdos or so...

but look at this: http://gparted.sourceforge.net/larry.../2-main-2a.gif

is your FAT32 partition within an extended? i can see a flags column with lba in the picture. can you flag the FAT32 partition after you created it? or the extended, if you use one?

good luck, vadkutya

@vadkutya

I think gparted does have an LBA checkbox but you would expect it to do that itself in that case.

Most of the "issues" affect old msdos software so I won't waste time with it here.

So here is what I learned so far:

After spending way too much time at Wikipedia under Logical Block Addressing and a dozen or so links from the references section, I decided to zero both sda & sdb and just see what Windows would do.

1. During install select a 5000MB C: Drive (/dev/sda1)
2. Finish install & reboot
3. Using the Disk Management thing, create a 2000MB D: (/dev/sda2) & a 10,000MB E: (/dev/sda3)
4. Reboot to SystemRescueCD

The results were surprising...
It appears that you should use 0x0b even on LBA drives as long as the created partition does not touch cylinder 1025 or above.

I would like to thank MICROS~1 for not putting this information anywhere in their knowledge base.

hey onedingo,

it seems that the horse doesn't jump higher than it has to ;). 0x0b (FAT32 without LBA) still uses the old BIOS INT 13 (low level disk read/write) which means it can adress a maximum of 7.8GB disk space. you created a partition of first 5GB than 2 GB (= 7GB) so windows is not forced to use BIOS INT 13h extensions. with the third partition however, it switches to LBA because it has to.

so far so good, but you created a primary partition with gparted which is 40GB. according to my understanding it must use BIOS INT 13h extension, hence no (E)CHS is possible and LBA is the only alternative. so the ID should be c NOT b. i am really confused by now...

maybe it's really a bug. on the other hand. unless you really install windows it doesn't matter since windows will setup the correct mode. the question remaining is can you access the whole 40GB if you mount the hd under linux. this shouldn't be possible. but i am not a hardware expert, sry...

vadkutya

one additional point. the oder in which the partitions appear in fdisk is not neseccariliy the order in which they reside on your hd. if the BIOS uses only the INT13 routines it cannot map higher than 7.8GB so the FAT32 partition would be out of range. however, if the order is reverse this is no problem. also, if the os is linux the FAT format is not of interest since linux uses LBA.

addendum:

maybe gparted doesn't care about 0x0b/0x0c if you don't tell it explicitly. it doesn't really have to. the defaul might be 0x0b. if you install windows then this will be handeled during windows installation. if not and you use linux then linux talks with the BIOS and the BIOS with the disk controller and the disk controller maps it all to the correct physical adress. so if linux handles your partition this should be no problem.

but as i said before. i'm not really sure about all this.
hope this helps, vadkutya

I have a better idea: just don't use FAT for anything. There is no longer any reason to, and it is a primitive, limited, and error prone file system.

NTFS can now be read and written from Linux, though it is slow, and ext2/3 can be read/written from Windows. So why use FAT?

Old thread but still it is useful to update old information:

> NTFS can now be read and written from Linux, though it is slow, and ext2/3 can be
> read/written from Windows. So why use FAT?

I have had issues with NTFS just recently. I could not modify it. No file I created
was really created. I could read the content and copy it, after I put it from my
windows box onto the external hdd. But I could not modify it.

This had something to do with the ntfs3 drivers or something. Rather than wanting
to find out what was the case I changed to vfat. And now I can modify this easily.

Perhaps NTFS is better and nicer on windows, but I am simply giving an example to
the above "why use FAT". In particular VFAT is still useful. Hopefully NTFS
support in Linux will one day be great, but until then even in 2022 you STILL can
have and run into issues. I even read on the www how windows can cause ntfs3 to
honour some weird fast boot setting and make no modification. I have no idea why
NTFS did not work for me here but I had no time to debug this any further, thus
vfat to the rescue (I use an external hdd to transfer my stuff onto windows
machines; I have too much data to omit, lots of open source .exe and .msi files
I need, lots of programming source code I use, including java these days).

FAT32 has a 4GB file size limit so if you have a lot of 4GB+ files, have a look at exFAT.