Vista API and >32GB Fat32 partitions

[no-mbr]

Anyone have a good idea of why Vista diskmgmt snap in will not create Fat32 partitions larger than 32GB? Actually <31768MB> ??

Yet, using 3rd-party non-Vista based utilities - large (FAT32) partitions can be created and then recognized in Vista......

What is different about Vista's operating of NTFS, FAT32?

[SufferWell1396]

FAT32 partitions CAN be over 32GB, but FAT32 has trouble managing them.
due to this, Vista wont let you create FAT32 partitions bigger than 32 GB

[Paul Komski]

FAT32 partitions can be pretty big. The maximum possible number of clusters on a volume using the FAT32 file system is 268,435,445. With a maximum of 32 KB per cluster and with space for the file allocation table itself, this equates to a theoretical maximum disk size of approximately 8 terabytes (TB).

The biggest FAT partitions I have used have been 500GB and Windows, to my knowledge, has had no intrinsic problem with them.

The 32GB limitation is nothing new to Vista and the windows formatter in earlier NT-based OSes such as Win2K and WinXP also would not create partitions larger than 32GB. As long as partitions greater than 32GB are created with other tools windows has no real problems in utilising them. Certain tools however, such as scandisk, can only operate on volumes up to 127GB in size.

[no-mbr]

Right - I've forgot - I guess I did first see this issue in XP - OK so next question - what's the deal with Vista not allowing four primary partitions?

The way I remember - the file system wants to hold on to some reserve space for the new "tagging" <meta files> abilities - do I remember this right?

Signed,
No Memory or Master Boot Record...... thanks.

[Paul Komski]

what's the deal with Vista not allowing four primary partitions?First I've heard of it. Do you have a reference?

4 primary partitions is standard on a normal MBR - one of which can be an extended partition. I've never known this area to be OS-related. Windows itself has tended to always deprecate (with the exception of extended partitions) anything other than one primary partition.

[no-mbr]

No, this is just from screwing around with a couple of new PC.

I've been multi-booting 5 and six OSs on several disks on at least 2 PCs and discovered an unusual situation. When ever I use diskmgmt snap in to add another 3rd partition, and in leaving "unallocated space" - if I come back and try to create another partition, the tool creates a volume instead in the "unalocated space" of the third partition, so it isn't bootable, it's a logical volume. And no - the 3rd partition - never did use the whole disk.....

I believe Partition Commander and or Acronis etc - will allow and create the partitions...... outside of Vista.... I guess another thing to check would be to use diskpart commands instead. Diskpart reveals what's "real" to win32 OS....

Anyway, anyone with an empty disk to screw around with - could help by verfying - in attempting to create 4 primary partitions with diskmgmt.msc in Vista.

Now I wonder if it will work on a disk with no OS installed.......

[Paul Komski]

It seems there are a number of limitations with using Vista's Disk Managment and this includes not allowing the user to decide what type of partitions to create. It will decide for you to first create up to three primary partitions and the fourth one will always be an extended partition containing a logical partition.

See http://elssblog.blogspot.com/2006/06/disk-management-in-windows-vista.html

So looks like you will have to do this using another tool outside of windows if you want four primaries. Just typical MS BS.

[saphalline]

The biggest FAT partitions I have used have been 500GB and Windows, to my knowledge, has had no intrinsic problem with them.Windows itself does not, but I think the formatting limitations imposed in the DskMgmt are related to poor Windows trying to protect itself.

On a number of occassions with cr@ppy OEM systems, such as default out-of-the-box HP Pavilions and whatnot, all the junk running in the background wreaks havoc on FAT32! I've seen a few rare cases of 80GB+ FAT32 partitions growing unrepairable file system errors seemingly out of thin air. Converting the partitions to NTFS, immediately after a boot-time chkdsk /r, can "cure" this issue with cr@pware, but some of the data is irretrievable. As far as I've seen, some of this junk OEM cr@pware uses excessive caching routines (only visible when showing hidden/system files) that somehow "overloads" the FAT32 file system but does not affect NTFS. Or so it seems.

Anyone have a thought as to why this might possibly happen? Other than poor coding, of course. :p ;)

[mjc]

One other thing to take into account, Saph...

Most vomit-boxes have write-behind caching enabled, along with all that cr@pware running...what happens when you reboot something that has that much running that is doing its own caching AND doing write-behind?

Simple...really...

All the caches NEVER get written/cleared/whatever...why do you think that many of them don't have reset buttons?

[saphalline]

Most vomit-boxes have write-behind caching enabled:eek: Good Lord Almighty!! I knew there was a reason I never went into PC repair a la Geek Squad!!

I'm going to give my custom-build a big hug now... *hugz*

[Paul Komski]

Most vomit-boxes have write-behind caching enabledI think windows enables write-caching on all fixed drives by default and disables it by default on removable drives - so, just to be clear, that setting is unlikely to be OEM related.

That the OEM's often install a lot of background rubbish that runs in the background is usually the case. The more programs that are open and the more running in the background, then the likelier it is that a premature or uncontrolled shutdown of any sort will mean that cached data has not been committed to disk. There was a specific problem with fast shutdown in WinME (that was later fixed by a patch) that specifically did make such corruption more likely.

Whilst it is true that any premature shutdown can cause data loss and file corruption (not only because of write caching but also because of file-locking or programs "not responding" and so forth) and that it is also true that because of journalling under NTFS that such corruption is less-likely to corrupt the metadata (mft or fat tables) on NTFS devices than on FAT devices this doesnt make NTFS immune. Systems should always be shut down in a controlled manner.

Databases, in particular, often use their own write-caching (different from the native file i/o) for particular performance reasons and because they often operate in a multi-user environment. Though that is not the actual issue here, it makes the orderly shut down of such systems even more critical than normal. It is a good practice to shut down such apps prior to shutting down the system - a good general principle in any case.

I think the formatting limitations imposed in the DskMgmt are related to poor Windows trying to protect itself.Be that as it may or may not be the case the next two logical questions would be (1) why 32GB and not 40GB or 80GB or 128GB and (2) specifically why should file corruption not be an issue below 32GB FAT partitions (whether or not write caching is enabled) but is somewhat magically the case over 32GB. If there is a specific reason for the 32GB threshold it would be very, very informative to know why. I have mentioned the scandisk limitation at the 128GB level but apart from that I am not aware of other Windows32 apps having problems with large FAT partitions up to the 1 or 2TB level.

.. uses excessive caching routines (only visible when showing hidden/system files) that somehow "overloads" the FAT32 file system but does not affect NTFS. Or so it seems.This hypothesis is anecdotal and I can't accept that is what is going on unless there is some article or reference that explains this. Corruption due to disk-caching occurs from premature or uncontrolled shut-down or when "things" cant be properly closed before shut down and not due to the file system per se. Files that are on disk and which are accessible (whether hidden or not) have been commited there; the disk cache data is held in RAM (or VM) and thus not yet written to the data areas of the disk.

[Paul Komski]

It appears that you may well be able to create the fourth primary partition in vista if you use the DiskPart command line utility. Assuming you have an empty hard drive then, if it works as in WinXP which I believe it should do, you should be able to create four (as of yet unformatted) partitions (in the example that follows here of 1, 2, 3 and 2.5 GB in size respectively). Commands entered by the user are in dark red.

########### START ###########
C:> diskpart
DISKPART> select disk 0
Disk 0 is now the selected disk.

DISKPART> detail disk
WDC WD1200JB-32EVA0
Disk ID: 985A6E42
Type : IDE
Bus : 1
Target : 0
LUN ID : 0
There are no volumes.

DISKPART> create partition primary 1000
DiskPart succeeded in creating the specified partition.

DISKPART> create partition primary 2000
DiskPart succeeded in creating the specified partition.

DISKPART> create partition primary 3000
DiskPart succeeded in creating the specified partition.

DISKPART> create partition primary 2500
DiskPart succeeded in creating the specified partition.
########### END #############

Just be careful choosing the correct disk - the details should confirm you are where you want to be. If you already have three primaries, no extended and some unallocated space and want to fill that space with a primary partition the commands should be just:

C:> diskpart

DISKPART> select disk 0
Disk 0 is now the selected disk.

DISKPART> create partition primary


You could also have a read of: http://vistarewired.com/2007/04/07/how-to-work-with-partitions-in-windows-vista-xp-when-disk-management-doesnt-work/

[sassie05]

If write - behind caching is enabled; when would this take place? Upon closing the application(s)?

[mjc]

Disk idle times and shutdown...but if it bottlenecks at shutdown, then data could be lost, file system corruption can occur, etc. If there is a sudden, unexpected shutdown (power failure, etc) then you could be in a world of hurt. Also, with it disabled on USB devices, there is less chance of corruption if the device is removed without first disconnecting it using the little disconnect icon in the system tray.

[sassie05]

Ahhh, thanks mjc:)

[no-mbr]

Thanks for checking into diskpart and 4 pri-parts... I've had to move on to other support issues. As far as comments about file system stability - I think at least some "gotchas" on OEM systems are a result of applications competing for file-writing priority while "system restore" is attempting to image an OS.

In the case of Vista, it seems the the search index feature takes a while on a fresh OEM system - since a new user has just been created. It's best to start one of these boxes up and go out for coffee for 30 minutes - just to see how many apps wanted to pop you a question.........after booting...