The pendrives cannot be formatted with fat32, why?

A lot of USB pendrives cannot be formatted with fat32, note on their manuals. What is the cause of the restriction? Any opinion is welcome. :)

Reply to
yukuan
Loading thread data ...

Where did you see that kind of restrictions ? I'm allways using FAT32 on that kind of USB_Stick ;-) One reason of that kind of restriction could be the cluster size that is smaller than an erase sector of the device. Is usbstor that bad that it can not manage this ?

Just go away of those devices because if they can't do this it probably also means quicker flash wear-out as the sector are more often re-used.

yukuan wrote:

Reply to
Bibico Cando

If the device has fewer than 65525 (yes, 65525) clusters, it *cannot* be formatted FAT32. If it has 65526 or more clusters, it *must* be formatted FAT32. And as a practical matter, you should avoid disk sizes within +/-16 clusters of that boundary (since there are many flawed implementations in the world). Assuming a few reserved sectors and 512 bytes clusters, it's pretty much impossible to format a 32MB device as FAT32. With 1KB clusters you're right on the edge with 64MB devices. The common defaults use FAT16 for up to about 512MB devices, with 8KB clusters, although those can typically be forced to use FAT32 by forcing a smaller cluster size during the format).

Reply to
robertwessel2

This argument has a rather fatal flaw: devices don't have clusters, they have sectors.

Clusters are a property of (some) filesystems, so their number cannot possibly be used as an argument in the decision between different types of file system.

There's actually a considerable intermediate range of sizes (roughly from 256 MiB to 2 GiB) that could be formatted equally well as FAT16 and FAT32 --- *in principle*. The catch is that at least one widely used OS flat-out refuses to give the user this choice, because its makers firmly subscribe to the "we know best what's best for you" school of thought.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Given that we're talking specifically about FAT, the destinction is pretty artificial. All FAT formatted volumes have clusters, and the layout of the FAT itself is determined strictly by the resulting number of clusters (and with only an indirect relationship to the number and size of the sectors). If you've laid out your device such that it has fewer than 65525 clusters, you must use FAT16 (ignoring FAT12, for the moment), if there are more clusters, you must use FAT32.

Reply to
robertwessel2

And all devices just about to be formatted have none. So you cannot possibly use the number of clusters to decide which FAT format you'll have to use --- because that number doesn't exist yet. Your argument is circular.

*and* by the choice of FAT32 vs. FAT16. A volume formatted FAT32 will typically have a lot more clusters than the same volume made a FAT16, so both systems could be used, and both would be within their limits.

This "laying out the device" is called formatting, or in more precise term, setting up a file system. And *before* you do that, the decision between the two file systems, FAT16 and FAT32, has to be made. Once it's formatted, there's no decision left to make.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Hans-Bernhard Broeker wrote: [X]

[X]

How many of you actually use MiB and GiB ? And how do you pronounce them?

Reply to
Ignacio G.T.
[...]

I use them occasionally, when I expect the audience to understand what they mean and their use would prevent potential confusion.

I don't. I've never used them in converstation. My understanding is that MiB is short for MebiByte and is pronounced mebby-byte, and similarly for GiB/GibiByte/gibby-byte. Google might be able to confirm or deny...

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

Stop being silly, the choice is, by definition, circular.

The choices in file system are strictly related to the number of clusters on the volume, which has a straightforward relationship to the size of the disk, with some (important) fiddle for the reserved sectors. Going the other way, the available choices for cluster size, and thus the number of clusters on the volume is related to the choice of file system. The second relation is weaker given that there are many file system/disk size combinations which are not possible at all (for example, FAT32 on a 32MB volume, or FAT16 on a 8GB volume).

And to relate this back to the OPs question, you cannot "pick" FAT32 on a 32MB (or smaller) drive *at all*, but you can pretty much pick the cluster count (by picking the cluster size), which will lead back to the type of FAT you'll use. On a hypothetical 33MB disk, 16 or 32KB clusters will lead to FAT12, 512 byte clusters to FAT32 and anything in between to FAT16 (assuming nothing outrageous in the reserved area).

*And since we're being pedantic, the above all assumes 512 byte sectors.
Reply to
robertwessel2

I never heard about MiB or GiB But that is a GOOD notation to tell that no (real power of 2) size is used. Maybe "i" means inferior (in the sense of less MegaBytes...) Just sad that HD always are using this silly 1000 not 1024 based units. If we had real MB it seems that FAT32 could also be used on 32MB flash...

Dave Hansen wrote:

Reply to
Bibico Cando

You've got it backwards.

1 MB = 10**6 bytes 1 MiB = 2**20 bytes

"M" is an the abbreviation for the SI prefix "mega", so it cannot correctly be used to refer to 2**20.

"Mi" is an abbreviation for the IEC prefix "mebi".

formatting link

Main memory (e.g., DIMMs) are normally measured in MiB or GiB (though they aren't marketed that way).

Disk drives are normally measured in GB.

Reply to
Eric Smith

For most flash and solid state devices the size rating is in binary units anyway, and so the physical capacities are approximately real. So a 32MB flash card really does have 33,554,432 bytes of storage (as opposed to the 32,000,000 bytes you'd expect from a "32MB" disk drive). Of course various things knock the usable size down from that, although that happens for all media to various extents (you'd likely not see sectors reserved on a HD for wear leveling, for example).

But even if you had a drive with exactly 65536 512 byte sectors available (eg. a "real" 32MB drive), you could not format it FAT32. Even with a single FAT, over 130 sectors would be lost to the reserved and FAT areas, and that would leave too few 512 byte clusters to make a valid FAT32 volume. The smallest volume you could format as FAT32, with typical reserved areas (32 reserved sectors plus two FATs) is somewhere around 65823 512 byte sectors (give or take a couple of sectors). And it would be wise to avoid being near the FAT16/FAT32 cluster count boundary by at least +/-16 clusters, so practically somewhere around 65839 sectors.

Reply to
robertwessel2

Thanks a lot,

I had a similar older version that had not the ?iB...

Eric Smith wrote:

Reply to
Bibico Cando

Obviously you know well the limits, Once I saw a microsoft document where the criteria if it is FAT16 or FAT32 was clearly explained depending of the number of cluster around a little bit less than 64K.

What do you think, could it be possible to cheat by marking some sectors as bad sectors in FATs. If I remember well bad sectors are marked with 0xFFFFFFF7 in FAT32 ? The final idea is to have FAT32... even on a little too small device.

What are the 32 reserved sectors used for ?

Thanks for your help Bibico

snipped-for-privacy@yahoo.com wrote:

Reply to
Bibico Cando

There's a minor possibility you might get away with that, but probably not in most environments. First, anything that does a sanity check on the volume when mounting it (like the OS) will likely spit up when it looks at the size of the disk as reported by the lower layers (the BIOS or what's on the partition tables, for example), and compares that to what the sector count in the BPB is. I've not done any extensive testing, but I've seen several OS's refuse to mount FAT volumes with inconsistent parameters. Which only makes sense - if the BIOS reports a 40,000 sector drive, and the volume info claims the volume is 80,000 sectors, something is wrong, wrong, wrong.

Even if you get past that, you'll likely have problems with programs like scandisk that will look at the whole drive. Not to mention the fact that any drive health program is going to present rather alarming statistics for the number of bad sectors or clusters.

The question remains, though: other than having to code support for both formats (and doing both FAT16 and FAT32 is not really a big increase in difficulty), why not support FAT16 on small volumes? FAT16 basically requires that you delete a few things from the FAT32 format - there's fewer fields in the boot sector, no FSINFO structure, no backup boot sector, and (obviously) FAT entries are two bytes instead of four. Directory entries are the same (for FAT32 an otherwise used field is used to hold the high part of the initial cluster number), long filenames are supported identically on all FAT volumes.

Probably the single most significant difference is that the root directory is fixed on FAT16, and a "normal" directory structure on FAT32.

And the difference between FAT16 and FAT12 is even less - just the layout of the FAT itself.

The boot sector(s), a backup copy of sector zero, that sort of stuff.

32 sectors is the typical reserved area formatted by MS utilities, although MS typically only uses the first three sectors for the boot program and sector 6 for the backup of sector zero.
Reply to
robertwessel2

... snip ...

Please do not toppost. Your answer belongs after, or intermixed with, the *snipped* material to which you reply.

Cluster numbers must be reserved to, at least, mark bad clusters, unused clusters, and the last cluster in a file. Other space must be reserved for such things as the FAT tables themselves, the root directory, the boot record, etc.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

number of

Blatantly false. You can choose the size of a cluster.

Groetjes Albert

--

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
 Click to see the full signature
Reply to
Albert van der Horst

It's probably worth noting that NAND flash chips are available with either 512-byte (really 528 bytes) or 2048-byte (or 2112 bytes, most likely because the designers are Rush fans) pages.

-a

Reply to
Bassman59a

What part of, "...but you can pretty much pick the cluster count (by picking the cluster size)...", which was a few lines down in the post, didn't you understand?

In any event, the point was the comparison of the relationship between disk size and cluster count (quite straightforward*), and disk size and FAT type (much more complex).

*Disk size, less reserved areas, divided by cluster size --- simple (dare I say straightforward), no?
Reply to
robertwessel2

I never would do this for HD, but for flashcard especially in embedded world, it could be just enough... to have FAT32.

In fact the basic idea to use FAT32 is that it allow small clusters/sectors of just one atomic access of 512 Bytes. This could be of great advantage when working with flash, in case of power off...

snipped-for-privacy@yahoo.com wrote:

number

bad

Reply to
Bibico Cando

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.