 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Forum / Windows 98 / General Topics / February 2007fat16 question
i have a quick question historical question for FAT: why does the cluster size go up by a factor of two as the disk size increases by a factor of 2 when the FAT type reaches 16 bits??? Cluster size is determined by the partition size rather than the size of the disk. For example: 128 MB - 255 MB 4K 256 MB - 511 MB 8K 512 MB - 1023 MB 16K 1024 MB - 2048 MB 32K Why is it that way: don't know  SignatureRegards Ron Badour, MS MVP for W98 Tips: http://home.satx.rr.com/badour Knowledge Base Info: http://support.microsoft.com/default.aspx?pr=kbinfo >i have a quick question historical question for FAT: why does the > cluster size go up by a factor of two as the disk size increases by a > factor of 2 when the FAT type reaches 16 bits??? | Cluster size is determined by the partition size rather than the size of the | disk. For example: [quoted text clipped - 5 lines] | | Why is it that way: don't know http://www.microsoft.com/whdc/device/storage/default.mspx - LocFileSys.doc - Local File Systems for Windows --- AS EXAMPLE relating to fat32 File system limits are imposed by the file system driver. Maximum allocation units per volume in Windows 95 and Windows 98 with fat32 = 4,177,918 The value of an entry in the file allocation table for each allocation unit in FAT32 can range from 0x00000002 to 0x0FFFFFEF. Maximum volume size for Windows 95 and Windows 98 = 127.5 GB Allocation unit size for Windows 95 and Windows 98 = Any power of 2 between 512 bytes and 32768 bytes inclusive In Windows 95 and Windows 98, the CHKDSK and DEFRAG utilities cannot support file allocation tables larger than 16 MB-64 KB in size. The maximum number of allocation units that can exist on a FAT32 hard disk drive volume with Windows 95 and Windows 98: (File allocation table size)/(Bytes per FAT entry) - (First two reserved allocation unit numbers in the file allocation table) = (16 × 1024 - 64) × 1024/4 - 2 = 4,177,918 allocation units. The maximum FAT volume size for Windows 95/98: Maximum allocation units per volume × Maximum allocation unit size=4,177,918×32 KB, which is 127.5 GB. In Windows 95 and Windows 98 there is no volume size limit imposed by the Windows format (format.com) utility. ----- The above outlines that the relationship between fat - file alloc tables, cluster size, and the designed in limits for the associated disc format and the inter-relationship regarding all, including OS restrictions. Exceed these "design limits" and whatever modifications are imposed within the applicable OS, and errors occur. Microsoft has numerous articles within its Knowledge Base, related to or which attempt to explain relationships and reasonings, if one is really interested in an exact definition. Wikipedia has general reference - though NEVER rely on that for the final answer for anything. Remember that those who could provide EXACT answers are bound generally by non-discloser and other restrictive legal aspects, so the entries thereon are generally based upon research done by those not bound, and opinion/article formed from that. SignatureMEB http://peoplescounsel.orgfree.com/ BLOG - http://peoplescounsel.spaces.live.com/ Public Notice or the "real world" http://groups.google.com/group/the-peoples-law?hl=en - discussion group for general aspects of Law verses the Peoples' of the world "Most people, sometime in their lives, stumble across truth. Most jump up, brush themselves off, and hurry on about their business as if nothing had happen." Winston Churchill Or to put it another way: Morpheus can offer you the two pills; but only you can choose whether you take the red pill or the blue one. _______________ | >i have a quick question historical question for FAT: why does the | > cluster size go up by a factor of two as the disk size increases by a | > factor of 2 when the FAT type reaches 16 bits??? > File system limits are imposed by the file system driver. > Maximum allocation units per volume in Windows 95 and Windows > 98 with fat32 = 4,177,918 As I've proved recently, windows 98se can natively handle up to at least 40 million clusters (alloc units) in a single fat-32 volume. It is true that some apps (like scandisk DOS and Win version) do not function when the number of clusters exceeds some number (that number being something I have not confirmed for myself). The number of 4.1 million clusters is quoted often, yet I've never been able to FDISK/FORMAT a hard drive and have it create a volume with more than 1.x million clusters. > The maximum FAT volume size for Windows 95/98: > size=4,177,918×32 KB, which is 127.5 GB. I'm pretty sure that FDISK/Format will use 64kb cluster size when the volume exceeds 64 gb. I'll mess around with some 80 gb drives and see what fdisk/format will do with them. But like I said, there is something up with fdisk/format that makes them shy away from creating volumes with more than 1.x million clusters. They would rather increase cluster size vs upping the number of clusters. BTW - which program sets the cluster size when a drive is prepared for use: Fdisk or Format? | > File system limits are imposed by the file system driver. | > Maximum allocation units per volume in Windows 95 and Windows [quoted text clipped - 6 lines] | function when the number of clusters exceeds some number (that number | being something I have not confirmed for myself). | BTW - which program sets the cluster size when a drive is prepared for | use: Fdisk or Format? See you got your answer for what does what. But no answer for why? Think "by design". Remember XP is admittedly limited by Microsoft... and we already discussed, in the group, other "by design" limitations; particularly when using Microsoft tools. There are a number of third party "fdisking" and "formatting" tools, which exceed by far, Microsoft's offered versions.. still being developed in fact.. so pick something that actually does what it should and quit relying on these deliberately limited tools, yah gotta be an old dog that can't be taught new tricks to still be using them, `course dats just my opine. SignatureMEB http://peoplescounsel.orgfree.com/ BLOG - http://peoplescounsel.spaces.live.com/ Public Notice or the "real world" http://groups.google.com/group/the-peoples-law?hl=en - discussion group for general aspects of Law verses the Peoples' of the world "Most people, sometime in their lives, stumble across truth. Most jump up, brush themselves off, and hurry on about their business as if nothing had happen." Winston Churchill Or to put it another way: Morpheus can offer you the two pills; but only you can choose whether you take the red pill or the blue one. _______________ >As I've proved recently, windows 98se can natively handle up to at >least 40 million clusters (alloc units) in a single fat-32 volume. >It is true that some apps (like scandisk DOS and Win version) do not >function when the number of clusters exceeds some number (that number >being something I have not confirmed for myself). I think if you use the default cluster sizes, they will be scaled to avoid at least some problems. Long before FAT32 hits an addressability limit, more practical limitations set in; a huge FAT becomes a memorey hog, the longer critical periods during updates will increase the risk of corruption (that Scandisk may not be able to fix), and things get pretty slow. Generally, non-default cluster sizes can break compatibility with low-level tools that deive the expected cluster size from the volume size, assuming the defaults to be valid. >The number of 4.1 million clusters is quoted often, yet I've never >been able to FDISK/FORMAT a hard drive and have it create a volume >with more than 1.x million clusters. AFAIK there are parameters for Format that can force non0default cluster sizes. I've never needed this, tho. >I'm pretty sure that FDISK/Format will use 64kb cluster size when the >volume exceeds 64 gb. Let's have a look...nope, 32k clusters in a 300G FAT32 logical volume, but then again that was created by BING for use in XP, not FDisk and Format from a Win9x. BTW, FDisk gets really wobbly above somewhere like 50G (40G OK, 60G not OK) and cannot input sizes > 99G. >I'll mess around with some 80 gb drives and see what fdisk/format will >do with them. Unless you use the downloaded bugfixed FDisk, or the one from WinME, you won't get sensible treatment of > 50G HDs such as your 80G. >But like I said, there is something up with fdisk/format that makes them >shy away from creating volumes with more than 1.x million clusters. Maybe that's the "50G limit"? >They would rather increase cluster size vs >upping the number of clusters. That might be a practicality thing, as described above. >BTW - which program sets the cluster size when a drive is prepared for >use: Fdisk or Format? Format. FDisk can flag a volume or primary partition to be FAT16 or FAT32; if the HD is > 512M, you're asked "do you want large drive support?" and if Yes, such volumes will be marked as to be FAT32. If no, then everything is FAT16, regardless of HD or volume size. But it's Format that actually creates the file system. Until formatted, volumes may get drive letters from FDisk's ministrations, but any attempt to access the letter fails with "bad media descriptor", as there's no FAT created as yet. BTW: Unlike FDisk, Format reads the partitioning as it was noted by BIOS at boot time, rather than by reading the actual HD - that's why you have to restart after FDisk changes, before Format. >--------------- ---- --- -- - - - - Saws are too hard to use. Be easier to use! >--------------- ---- --- -- - - - - > a huge FAT becomes a memorey hog, Back in the days when having 32 mb of ram was jaw-dropping - maybe. But not today, not for years. > the longer critical periods during updates will increase > the risk of corruption (that Scandisk may not be able to > fix), and things get pretty slow. Over the years I've found that win98/fat32 to be pretty robust - nowhere near the "fragility" that you read about when fat is compared to ntfs. And like I've said before, NTFS gets fragged just as much as fat32, and a fragged win-2k system really bogs. Remember that win-98 doesn't run a million processes like NT OS's do. > Generally, non-default cluster sizes can break compatibility > with low-level tools that derive the expected cluster size > from the volume size, assuming the defaults to be valid. I highly doubt that defrag and scandisk wouldn't read the cluster size directly. I highly doubt that they would rely on their own computation of what they *think* the cluster size should be and then proceed from there. I'm sure I'm right, because I believe that the reason why scandisk and defrag exit with an "out of memory" error when faced with a non-standard (and very large) cluster count is because they are reading the cluster size from the fat or the MBR (or where-ever it's stored) and they kak because it exceeds the capacity of the variable type they use to hold it. > > I've never been able to FDISK/FORMAT a hard drive and have > > it create a volume with more than 1.x million clusters. (I retract that. Format will allow the cluster count to exceed 2 million, but only when the volume is larger than 64 gb). > AFAIK there are parameters for Format that can force non- > default cluster sizes. I've never needed this, tho. If you, or anyone else, can show me where fdisk or format has a switch or setting to allow the user to specify the cluster size, then please indicate that here. > > I'm pretty sure that FDISK/Format will use 64kb cluster size > > when the volume exceeds 64 gb. (I also retract that. It appears that max cluster size is 32kb) > Let's have a look...nope, 32k clusters in a 300G FAT32 logical > volume, but then again that was created by BING for use in XP, > not FDisk and Format from a Win9x. You realize that a 300gb volume formatted with 32kb clusters would result in over 9 million clusters. Win-98 defrag and scandisk would not be compatible with that. Win-98 itself would not be compatible unless the drive was either (a) a SATA drive, or (b) you were using a modified version of ESDI_506.PDR. You also realize that Win-2k and XP were "handicapped" in that they are not natively able to create fat-32 volumes larger than 32 gb. But I'm curious: Are XP's native drive-management tools compatible with a FAT-32 drive with so many clusters? That would make for an interesting contradiction if they were. > BTW, FDisk gets really wobbly above somewhere like 50G > (40G OK, 60G not OK) and cannot input sizes > 99G. The original win-98se version of fdisk was not able to correctly handle drives larger than 64 gb. MS released an update in 2000 that fixed that issue and allowed FDISK to correctly partition drives up to 128 gb. I'm not sure what the story is for drives (or volumes?) larger than 128 gb. The format.com program doesn't have a problem with volumes up to 128 gb but it does report the volume size incorrectly during operation (but that is cosmetic only). > > I'll mess around with some 80 gb drives and see what fdisk > > /format will do with them. > > Unless you use the downloaded bugfixed FDisk, or the one from > WinME, you won't get sensible treatment of > 50G HDs such as > your 80G. I've already posted my results regarding that - see my earlier post in this thread. You might also want to read another recent post titled "Cluster size and exploring the limits of FAT-32". > > But like I said, there is something up with fdisk/format that > > makes them shy away from creating volumes with more than 1.x > > million clusters. > > Maybe that's the "50G limit"? No. I really think that early on, someone at MS made a decision that given the memory and CPU specs available for the typical machine back when win-98 came out, that they decided to try to keep the cluster count limited to 2 million. What they did instead was to increase (double) the cluster size every time the 2-million cluster count was reached. When the drives reached 64 gb, they were already at cluster size of 32 kb and a cluster count of 2 million and they couldn't double the cluster size to 64 kb so they allowed the cluster count to rise above the 2 million mark, up to 4 million, which *may* be the limit of win-98's scandisk and defrag. But by then, having 128 or 256 mb of memory was normal, so it wasn't much of a performance hit to be dealing with 4 million clusters. All of this seemed to be timed so that drives (or volumes) larger than 128 gb would be more-or-less standard by the time that MS wanted win-98 to be completely dead. >> a huge FAT becomes a memorey hog, > >Back in the days when having 32 mb of ram was jaw-dropping - maybe. > >But not today, not for years. Check your calculations again. With your 40 million cluster drive that means there are 40 million entires in the FAT. Each entry is 32 bits (FAT32) which is 4 bytes. So to load the entire FAT into RAM would require 160 million bytes of RAM or 152.5 megabytes. That is a non-trivial amount of RAM, even by today's standards. Ron Martell Duncan B.C. Canada SignatureMicrosoft MVP (1997 - 2006) On-Line Help Computer Service http://onlinehelp.bc.ca Syberfix Remote Computer Repair "Anyone who thinks that they are too small to make a difference has never been in bed with a mosquito." >>> a huge FAT becomes a memorey hog, >> [quoted text clipped - 9 lines] > RAM or 152.5 megabytes. That is a non-trivial amount of RAM, even by > today's standards. Double that to include the backup copy for FAT32. >Double that to include the backup copy for FAT32. I know that Windows compares the two copies of the FAT to ensure that they are identical, but does it retain both in RAM? Ron Martell Duncan B.C. Canada SignatureMicrosoft MVP (1997 - 2006) On-Line Help Computer Service http://onlinehelp.bc.ca Syberfix Remote Computer Repair "Anyone who thinks that they are too small to make a difference has never been in bed with a mosquito." >>Double that to include the backup copy for FAT32. > > I know that Windows compares the two copies of the FAT to ensure that > they are identical, but does it retain both in RAM? Hmm.. you're right. There's really no good reason to keep both in memory. You just have to write to both locations using the same memory stored data. Back to your original estimate.. > So to load the entire FAT into RAM would require 160 million > bytes of RAM or 152.5 megabytes. That is a non-trivial amount > of RAM, even by today's standards. So tell me how one would monitor memory usage in DOS or in win-98 as the FAT is accessed? I could, for example, take out memory and bring the system down to maybe 8 mb, maybe 4 mb, and by your logic I wouldn't be able to perform what - a DIR command - while in DOS? Copy a file? Why is it necessary for the entire FAT to be loaded into memory? Perhaps for defrag it must be, but I don't see why it has to be for ordinary file read/write operations. >> a huge FAT becomes a memorey hog, >Back in the days when having 32 mb of ram was jaw-dropping - maybe. >But not today, not for years. It depends... if the FAT has to be locked in physical RAM, the effect is that much adverse, and it's updated so often that paging it to disk means frequent writes to disk. You (or was it MEB?) talk about 4 million clusters, which at 32-bits each, would be 16M, or heading towards 32 thousand sectors per copy of the FAT. If I were running Win98 in 32M RAM, I'd want to avoid that much RAM lock-down if I could, and if it were a volume not too sensitive to swap file efficiency, I'd do that by doubling the cluster size and halving the memory footprint, and maybe twice at that. Which is FAT32's default strategy. I'm not too obsessive about small cluster size on non-C: volumes; slack space is a factor, but not the only factor that's important to me. Compatibility with Scandisk is a must, and more efficient Scandisk and Defrag is good, too. >> the longer critical periods during updates will increase >> the risk of corruption (that Scandisk may not be able to >> fix), and things get pretty slow. >Over the years I've found that win98/fat32 to be pretty robust - >nowhere near the "fragility" that you read about when fat is compared >to ntfs. And like I've said before, NTFS gets fragged just as much as >fat32, and a fragged win-2k system really bogs. Remember that win-98 >doesn't run a million processes like NT OS's do. Yup - I agree, most of "NTFS is more reliable than FATxx" is bogus, either the result of deficiencies in XP (the Rt-click, Properties, Tools, Check for Errors doesn't find errors in FATxx volumes, though the formal ChkDsk does) or ASSumptions on the nature of file system errors and user priorities. The only self-healing trick NTFS has, is the ability to delete broken data after a bad exit interrupts sane file systrem operations - which is exactly the same as FATxx cleanup deleteing lost cluster chains and bad-length files. All it preserves is metadata and file system structure; your data is simply and irreversibly discarded. When it comes to other types of file system corruption, such as arbitrary sectors written to arbitrary locations inthe file system structure, NTFS has no magic tricks - and worse, no user-controlled tools for managing these things, much less recovering data. NTFS stores chaining info in a more efficient way, i.e. located within the dir entry and in the smaller form of start/length "run" entries rather than an explicit slab of all cluster next-addresses. But there's no second safety copy of this information. NTFS also stores directory entries more efficiently, so that large numbers of files per directory doesn't hurt as much as it does with FATxx. Combine these with support for files > 4G in size, and you can see that it's more efficient for large volumes than FAT32, no matter how you slice the cluster-size/FAT-size cake. If it were a properly documented standard backed up with effective repair and recovery tools, it would be a no-brainer to use NTFS instead of FAT32. If don't care about data loss, as vendor support centers don't have to, then that also makes it a no-brainer. But for the rest of us... >> Generally, non-default cluster sizes can break compatibility >> with low-level tools that derive the expected cluster size >> from the volume size, assuming the defaults to be valid. >I highly doubt that defrag and scandisk wouldn't read the cluster size >directly. I highly doubt that they would rely on their own >computation of what they *think* the cluster size should be and then >proceed from there. You'd want to test that for both DOS mode and Windows-based Scandisk, as well as Windows Defrag. In particular, DOS mode Scandisk is likely to fail because DOS XMS management has severe address-range limitations that may preclude holding huge FAT in RAM. >I'm sure I'm right, because I believe that the reason why scandisk and >defrag exit with an "out of memory" error when faced with a >non-standard (and very large) cluster count is because they are >reading the cluster size from the fat or the MBR (or where-ever it's >stored) and they kak because it exceeds the capacity of the variable >type they use to hold it. I think the variable type to hold it is the least likely problem, given that FAT32 has a clear 32-bit address size. In DOS mode, it's more likely an inability for HiMem.sys to provide Scandisk with enough XMS to hold the hige FATs. >> AFAIK there are parameters for Format that can force non- >> default cluster sizes. I've never needed this, tho. >If you, or anyone else, can show me where fdisk or format has a switch >or setting to allow the user to specify the cluster size, then please >indicate that here. It will be Format, not FDisk. I wish I knew the reference, but I don't; I'd have to Google it, just as you would. Then again, one would likely prefer 3rd-party tools for this stuff, given the pathetic limitations of FDisk and Format that apply > 50G or so. >> Let's have a look...nope, 32k clusters in a 300G FAT32 logical >> volume, but then again that was created by BING for use in XP, >> not FDisk and Format from a Win9x. >You realize that a 300gb volume formatted with 32kb clusters would >result in over 9 million clusters. Yep. I wouldn't like that with 4k clusters, heh heh... >Win-98 defrag and scandisk would not be compatible with that. They break over 137G in data-corrupting ways, so they were never in the frame to begin with. This is XP territory by this stage; I don't put anything > 137G into Win9x systems, and most of them aren't being repaired when they die of old age in 2006/7. >Win-98 itself would not be compatible unless the drive was either >(a) a SATA drive, or (b) you were using a modified version of >ESDI_506.PDR. I'd have to know a lot more about these things before trusting such fixes. Even XP SP1, supposedly OK > 137G, corrupts such volumes under particular circumstances (e.g. the memory dump handler), so if I can't trust a young post->137G OS to work, I'm unlikely to trust a far older OS with far less rigor directed at retrofitting these things. >You also realize that Win-2k and XP were "handicapped" in that they >are not natively able to create fat-32 volumes larger than 32 gb. But >I'm curious: Are XP's native drive-management tools compatible with a >FAT-32 drive with so many clusters? That would make for an >interesting contradiction if they were. Format (the CLI form) in both XP and Vista will start formatting a FAT32 > 32G, chug away to the 32G mark, and then fall on their a.s leaving a non-undoable mess. It's appallingly bad design and coding. ChkDsk and Defrag work OK in XP, and prolly in Vista (with such a non-existent UI to Defrag, who can tell?) but as I've noted earlier, Rt-Click access to file system checking in XP does hardly anything at all - very fast, and missed the deliberate hand-crafted errors I tested with (e.g. a chain that went 64 65 66 66 68...), which a subsequent DOS mode Scandisk found and fixed. >> BTW, FDisk gets really wobbly above somewhere like 50G >> (40G OK, 60G not OK) and cannot input sizes > 99G. >The original win-98se version of fdisk was not able to correctly >handle drives larger than 64 gb. MS released an update in 2000 that >fixed that issue and allowed FDISK to correctly partition drives up to >128 gb. I'm not sure what the story is for drives (or volumes?) >larger than 128 gb. FDisk is < 137G, but even the fixed one has an input text field incapable of handling > 99G. It's hopeless; walk away. >The format.com program doesn't have a problem >with volumes up to 128 gb but it does report the volume size >incorrectly during operation (but that is cosmetic only). Yep, that's what I noticed too. >> Maybe that's the "50G limit"? Referring to the FDisk limit that you've described as starting at 64G. I refer to it as a "50G limit" as I remember it as affecting 60G HDs too, with 40G being the last "OK" size. >All of this seemed to be timed so that drives (or volumes) larger than >128 gb would be more-or-less standard by the time that MS wanted >win-98 to be completely dead. MS were dumber than that, else XP would have been born truly 137G+ capable. As it was, they seemed to have struggled with delivering that, claiming success with SP1 but succeeding only with SP2. >--------------- ---- --- -- - - - - Saws are too hard to use. Be easier to use! >--------------- ---- --- -- - - - - > It depends... if the FAT has to be locked in physical RAM I highly doubt that DOS or Win-9x loads the (entire) fat into some special / protected block of memory as part of normal use. Sure, scandisk or defrag does this, but when have you ever issued a "mem" command while in DOS and have seen a memory block allocated to FAT storage? > You (or was it MEB?) talk about 4 million clusters, which ... According to this: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/s upport/kb/articles/Q184/0/06.ASP&NoWebContent=1 The 4-million cluster thing is related to some sort of array-size limitation or memory allocation limitation preventing an array larger than 16-million bytes being created for the purpose of storing the FAT by scandisk and (presumably) defrag. 16 million divided by 4 = 4 million. MS repeatedly says that scandisk is the reason why the cluster count is limited to 4 million. As I've pointed out, win-98 can be installed on and access volumes with up to at least 40 million clusters. MS says that scandisk is a 16-bit program (which means they should get their a.s kicked for writing an important app as 16-bits for a 32-bit OS). Probably planned to garantee a future handicap. But it's still a weak argument, given that third-pary drive tools don't have that limitation. > Compatibility with Scandisk is a must, If that were the only diagnostic and repair tool available, then yes. Otherwise no. > and more efficient Scandisk and Defrag is good, too. It's not a case of efficiency. 4-million clusters was not chosen as the upper limit because of efficiency. Besides, the use of scandisk and defrag is sporadic if not rare. On the other hand, the waste that comes from using absurdly large clusters (32kb) is always with you. > (ntfs) support for files > 4G in size The 4-gb file size limitation is (to me) over-blown. Even DVD's store data as 1-gb VOB files. > (ntfs) it's more efficient for large volumes than FAT32 Give me the same variety of third-party diagnostic and repair tools for NTFS as currently exists for FAT, and give me a true command shell that I can boot into for NTFS, and I might look more favorably on NTFS as being all-around better than FAT-32. If win-98 was fully NTFS compatible, and I could still boot into DOS on an NTFS system, then I'd probably run 98 on NTFS vs FAT-32 if I had the choice. Or, put it another way, I wouldn't choose to run 2K or XP because that's the only way I can experience NTFS (not that I run 2K or XP anyways). Then again, if scandisk and defrag were not limited to 4 million clusters, then I'd say that FAT-32 and NTFS was a draw. > If it were a properly documented standard backed up with > effective repair and recovery tools, it would be a no- > brainer to use NTFS instead of FAT32. Yes, I guess I said something similar above, but you left out the part about Win-98 being compatible with NTFS as well. > > I believe that the reason why scandisk and defrag exit with > > an "out of memory" error when faced with a non-standard (and [quoted text clipped - 7 lines] > In DOS mode, it's more likely an inability for HiMem.sys > to provide Scandisk with enough XMS to hold the hige FATs. Given all that's been discussed so far, it's this 16-mb array allocation that's the problem for scandisk, and on most systems today with 128, 256 or 512 mb of ram, that shouldn't be a problem. > > If you, or anyone else, can show me where fdisk or format > > has a switch or setting to allow the user to specify the > > cluster size, then please indicate that here. > > It will be Format, not FDisk. I wish I knew the reference, > but I don't; format /? does not show an option to set cluster size. > Then again, one would likely prefer 3rd-party tools for this > stuff, given the pathetic limitations of FDisk and Format > that apply > 50G or so. I disagree. If one could specify the cluster size with format, then you'd have no reason to resort to a third-party tool. You'd still be left with the situation that the largest volume you could have with 4kb cluster size would be 16 gb (assuming you want full compatibility with scandisk and defrag). > > You realize that a 300gb volume formatted with 32kb clusters > > would result in over 9 million clusters. [quoted text clipped - 5 lines] > They break over 137G in data-corrupting ways, so they were > never in the frame to begin with. There is a modified version of ESDI_506.PDR that allows 98 to function correctly with IDE drives larger than 137 gb. Alternatively, SATA drives larger than 137 gb will be compatible if you're running them on something like a Silicon Image controller. > This is XP territory by this stage; I don't put anything > 137G > into Win9x systems, Soon I'll be running 98se on a socket-775 motherboard with (2) 500-gb SATA drives. > > Win-98 itself would not be compatible unless the drive was > > either (a) a SATA drive, or (b) you were using a modified > > version of ESDI_506.PDR. > > I'd have to know a lot more about these things before trusting > such fixes. I've already used a 160 gb SATA drive enough to prove to me that it works fine. Since I plan to basically stick to SATA for drives larger than 80 gb I don't see myself being in a position to try the modified ESDI_506.PDR (it's for IDE drives only), but you can read about it on the MSFN.org win-98 forums where it were created last summer. > Even XP SP1, supposedly OK > 137G, corrupts such volumes under > particular circumstances (e.g. the memory dump handler), so if > I can't trust a young post->137G OS to work, Well, you can remain unconvinced, but I'm telling you that SATA drives larger than 137 gb work fine under win-98. That's because the ESDI_506.PDR driver is not used in that case - that's the driver that win-98 uses for 32-bit protected mode drive access for IDE drives, and as shipped by MS it's got a 137 gb limitation. > I'm unlikely to trust a far older OS with far less rigor directed > at retrofitting these things. There's no retrofitting required for SATA drive use. The driver that comes with either your motherboard or a SATA controller card will come with win-98 drivers, and they were written for full 48-bit LBA compatibility. The only caveat is that the SATA driver that's part of Intel's ICH5R southbridge doesn't function correctly with win-98, but most motherboards in the past 3 years have a Silicon Image SATA driver anyways. > Referring to the FDisk limit that you've described as starting > at 64G. I refer to it as a "50G limit" as I remember it as > affecting 60G HDs too, with 40G being the last "OK" size. The newer FDISK has no problems working with 80 gb IDE drives. I've used it many times for that drive size. I'll try it on a 160 gb SATA drive and report back my findings. > snip >> > If you, or anyone else, can show me where fdisk or format [quoted text clipped - 6 lines] > format /? does not show an option to set cluster size. > snip That's because it is an "undocumented" switch (Google undocumented format switches), although it has been mentioned on various web sites and in newsgroups for years: FORMAT drive: /Z:n formats a FAT32 drive with a cluster size of n times 512 Bytes. n - number of sectors per cluster multiplied by 512 = cluster size in Bytes Examples: n = 1 creates a 512 Bytes cluster n = 2 creates a 1024 Bytes (1 KB) cluster n = 8 creates a 4096 Bytes (4 KB) cluster n = 16 creates a 8192 Bytes (8 KB) cluster and so forth. SignatureGlen Ventura, MS MVP Shell/User, A+ http://dts-l.org/ > > format /? does not show an option to set cluster size. > [quoted text clipped - 3 lines] > FORMAT drive: /Z:n > formats a FAT32 drive with a cluster size of n times 512 Bytes. Good information. Not knowing that format had hidden switches, I didn't make an attempt to look for any. Like you said, here's a few places where they are mentioned: http://www.dx21.com/TIPS/ViewItem.ASP?OID=4&OS=MS-DOS&S=MS-DOS http://www.geocities.com/rick_lively/MANUALS/COMMANDS/F/FORMAT.HTM http://www.geocities.com/~budallen/dosecrete2.html > > Referring to the FDisk limit that you've described as starting > > at 64G. I refer to it as a "50G limit" as I remember it as [quoted text clipped - 4 lines] > > I'll try it on a 160 gb SATA drive and report back my findings. See my next post (Update 2: Cluster size and exploring the limits of FAT-32) >> It depends... if the FAT has to be locked in physical RAM >I highly doubt that DOS or Win-9x loads the (entire) fat into some >special / protected block of memory as part of normal use. Sure, >scandisk or defrag does this, but when have you ever issued a "mem" >command while in DOS and have seen a memory block allocated to FAT >storage? Interesting point... mind you some stuff doesn't appear in Mem >> Compatibility with Scandisk is a must, >If that were the only diagnostic and repair tool available, then yes. >Otherwise no. Are there free Scandisk replacements available? As Norton isn't free. >Besides, the use of scandisk and defrag is sporadic if not rare. On >the other hand, the waste that comes from using absurdly large >clusters (32kb) is always with you. It's not that big a deal - personally, aside from the paging efficiency factor, I think the whole "cluster bloat" thing is way over-hyped. For one thing, large FATs take up disk space that offsets what you'd gain from cluster slack space, and for another, there are usually other often-wasted opportunities to recover space. >> (ntfs) support for files > 4G in size > >The 4-gb file size limitation is (to me) over-blown. Even DVD's store >data as 1-gb VOB files. It's a problem when you want to image an entire DVD (and we aren't talking DVD movies here; think Bart, WinPE, custom isnstall DVDs) >> (ntfs) it's more efficient for large volumes than FAT32 > >Give me the same variety of third-party diagnostic and repair tools >for NTFS as currently exists for FAT, and give me a true command shell >that I can boot into for NTFS, and I might look more favorably on NTFS >as being all-around better than FAT-32. The directory efficiency is a fairly compelling performance advantage, but if the data's at risk for unrecoverability, I'm not interested. >I wouldn't choose to run 2K or XP because that's the only way >I can experience NTFS (not that I run 2K or XP anyways). NTFS becomes more useful, even obligatory, as XP and later OSs assume it is there. For example, Vista won't run on FATxx properly, and if you relocate Windows Mail onto FATxx, you have the serious impact of huge numbers of loose files in a single directory, if each email message is stored as a separate file. I can't see any point in running a pre-NTFS OS on NTFS; it's just going to treat it as FATxx anyway. >> It will be Format, not FDisk. I wish I knew the reference, >> but I don't; >format /? does not show an option to set cluster size. That's why I needed a reference :-/ >> Then again, one would likely prefer 3rd-party tools for this >> stuff, given the pathetic limitations of FDisk and Format >> that apply > 50G or so. >I disagree. If one could specify the cluster size with format, then >you'd have no reason to resort to a third-party tool. You'd still be >left with the situation that the largest volume you could have with >4kb cluster size would be 16 gb (assuming you want full compatibility >with scandisk and defrag). As I say, I'm not bothered about cluster size off C:, and actively prefer large clusters for crucial small files; that's why I use FAT16 for "office" data and other such material. >There is a modified version of ESDI_506.PDR that allows 98 to function >correctly with IDE drives larger than 137 gb. > >Alternatively, SATA drives larger than 137 gb will be compatible if >you're running them on something like a Silicon Image controller. All of which sounds messy and fragile. I've moved off Win9x on that sort of hardware, in favor of XP SP2. >Soon I'll be running 98se on a socket-775 motherboard with (2) 500-gb >SATA drives. :-) >I've already used a 160 gb SATA drive enough to prove to me that it >works fine. Since I plan to basically stick to SATA for drives larger >than 80 gb I don't see myself being in a position to try the modified >ESDI_506.PDR (it's for IDE drives only), but you can read about it on >the MSFN.org win-98 forums where it were created last summer. Interesting! >Well, you can remain unconvinced, but I'm telling you that SATA drives >larger than 137 gb work fine under win-98. That's because the >ESDI_506.PDR driver is not used in that case - that's the driver that >win-98 uses for 32-bit protected mode drive access for IDE drives, and >as shipped by MS it's got a 137 gb limitation. I'm wondering about limitations within the OS itself, i.e. assumptions about file system structure etc. >The only caveat is that the SATA driver that's part of Intel's ICH5R >southbridge doesn't function correctly with win-98, but most >motherboards in the past 3 years have a Silicon Image SATA driver I use only Intel chipsets. Seems like add-on Silicon Image SATA doesn't work too cleanly in Vista, either. >> Referring to the FDisk limit that you've described as starting >> at 64G. I refer to it as a "50G limit" as I remember it as >> affecting 60G HDs too, with 40G being the last "OK" size. >The newer FDISK has no problems working with 80 gb IDE drives. I've >used it many times for that drive size. >I'll try it on a 160 gb SATA drive and report back my findings. The first ?50G limit is fixed by the fixed FDisk (or WinME's native FDisk) but the 99G input field limit is not. BING is so much faster that I just see no reason to worry with FDisk except to quickly manipulate Active status or do an /MBR >--------------- ---- --- -- - - - - Saws are too hard to use. Be easier to use! >--------------- ---- --- -- - - - - >>BTW - which program sets the cluster size when a drive is prepared for >>use: Fdisk or Format? [quoted text clipped - 12 lines] > BIOS at boot time, rather than by reading the actual HD - that's why > you have to restart after FDisk changes, before Format. Chris! Actually,, it may be for the reason that the OS (DOS or Windows) can't insert the "drive" into the device chain until after the reboot. Certainly there's no DOS API for fdisk to do so.. AYK, As far as the BIOS is concerned it's just a fixed disk. On Fri, 23 Feb 2007 15:30:28 -0500, "Bill Blanton" >"cquirke (MVP Windows shell/user)" >> BTW: Unlike FDisk, Format reads the partitioning as it was noted by >> BIOS at boot time, rather than by reading the actual HD - that's why >> you have to restart after FDisk changes, before Format. >Chris! Hi! >Actually,, it may be for the reason that the OS (DOS or Windows) can't >insert the "drive" into the device chain until after the reboot. Certainly >there's no DOS API for fdisk to do so.. >AYK, As far as the BIOS is concerned it's just a fixed disk. FDisk does read the partition table every time it starts, so it's safe to do this... - FDisk, "Yes" - create FAT32 volumes - exit FDisk - FDisk, "No" - create FAT16 volumes - exit FDisk - FDisk, "Yes" - create FAT32 volumes - exit FDisk - reboot - Format volumes to taste ...but not this... - FDisk, "Yes" - create FAT32 volumes - exit FDisk - FDisk, "No" - create FAT16 volumes - exit FDisk - FDisk, "Yes" - create FAT32 volumes - exit FDisk - Format volumes to taste ...i.e. you MUST reboot before Format, but you don't need to reboot between successive FDisk sessions. >--------------- ---- --- -- - - - - Saws are too hard to use. Be easier to use! >--------------- ---- --- -- - - - - > On Fri, 23 Feb 2007 15:30:28 -0500, "Bill Blanton" >>"cquirke (MVP Windows shell/user)" [quoted text clipped - 6 lines] > > Hi! Hey! >>Actually,, it may be for the reason that the OS (DOS or Windows) can't >>insert the "drive" into the device chain until after the reboot. Certainly [quoted text clipped - 31 lines] > ...i.e. you MUST reboot before Format, but you don't need to reboot > between successive FDisk sessions. Right. Point was it's not that format needs to read BIOS params, rather that it needs the "drive" (C:, D:, E:, etc:) in the DOS device chain in order to use DOS interrupts on the "drive" (letter). In order for that to happen, a reboot is necessary. On Mon, 19 Feb 2007 13:25:41 -0500, "MEB" <meb@not real@hotmail.com> >http://www.microsoft.com/whdc/device/storage/default.mspx >--- AS EXAMPLE relating to fat32 <lovely detail snipped> >Remember that those who could provide EXACT answers are >bound generally by non-discloser and other restrictive legal aspects That's likely to be true for NTFS, but AFAIK FATxx (certainly FAT16) is open, in the sense that it's publically documented. This is one of the reasons why one might prefer FATxx over NTFS. >--------------- ---- --- -- - - - - Saws are too hard to use. Be easier to use! >--------------- ---- --- -- - - - - | On Mon, 19 Feb 2007 13:25:41 -0500, "MEB" <meb@not real@hotmail.com> | [quoted text clipped - 16 lines] | Be easier to use! | >--------------- ---- --- -- - - - - True, and several thousand [or more likely hundred thousand] sites have already addressed the aspects being discussed here. Fat12 and Fat16 were not solely Bill Gates [hence Microsoft's] creations. Unlike Microsoft, IBM was far more interested in informing its technicians of the "ins and outs" of the workings of the OS, and they provided portions of that to the world. Several other fat based OSs were created which also were typically more open about the workings. Even Wikipedia has a relatively good historical reference: http://en.wikipedia.org/wiki/Fat16 Interesting to see the government's turn around on the Appeals for patents, after Microsoft began working WITH [under] the government. Gosh, nothing obvious going on here is there... See the inclusion on wikipedia for a brief indication. Note specifically the timelines in comparison with other cases against Microsoft and the final patent allowance on 01-10-2006. And yes, I was referring to NTFS for being still under "wraps",, Microsoft does have complete control over that format. SignatureMEB http://peoplescounsel.orgfree.com/ BLOG - http://peoplescounsel.spaces.live.com/ Public Notice or the "real world" http://groups.google.com/group/the-peoples-law?hl=en - discussion group for general aspects of Law verses the Peoples' of the world "Most people, sometime in their lives, stumble across truth. Most jump up, brush themselves off, and hurry on about their business as if nothing had happen." Winston Churchill Or to put it another way: Morpheus can offer you the two pills; but only you can choose whether you take the red pill or the blue one. _______________ >Cluster size is determined by the partition size rather than the size of the >disk. For example: [quoted text clipped - 5 lines] > >Why is it that way: don't know It's to do with addressing. The File Allocation Table address size sets an absolute maximum on how many clusters can be addressed in order to store file data within them, and when your file system has to address volumes that are "too big", then you have to store more data per cluster to overcome this limit. It goes up in multiples of 2 for reasons of machine efficiency, I suspect. FAT16 can address under 65535 clusters, and that bits quite deep, forcing cluster size increases as in that table (where the max is 2047, not 2048). NT can use 64k clusters for up to 4G volumes. FAT32 flattens the problem, in that 32-bit addresses can address a range of space so large that the FAT itself becomes a limiting factor. So cluster sizes double in FAT32 as well, but at points far short of 32-bit addressing limitations, simply to keep the File Alliocation Tables small enough to manage in memory. In fact, free space is now "cached" in the boot record instead of being calculated afresh from the FAT itself, for efficiency reasons. I think the FAT32 rollover points are... 512 MB - 7.9 GB 4K 8 GB - 31.9 GB 8K 32G - 127G 16k 128G+ 32k ...or something; not sure of the last two rollover points, but I'm well familiar with the 8G limit as 4k clusters are particularly desirable for paging to disk. >--------------- ---- --- -- - - - - Saws are too hard to use. Be easier to use! >--------------- ---- --- -- - - - - > I think the FAT32 rollover points are... > > 512 MB - 7.9 GB 4 K > 8 GB - 31.9 GB 8 K > 32 GB - 127 G 16 k > 128 GB+ 32 k Remember that it's the DOS format program that determins what the cluster size will be. And format likes to keep the total number of clusters from exceeding 2 million. So your table above actually looks more like this: 4 GB (?) - 7.9 GB 4 k 8 GB - 15.9 GB 8 K 16 GB - 31.9 GB 16 k 32 GB - 63.9 GB 32 k 64 GB - 128 GB 32 K 128 GB+ ????? The 64 to 128 gb range keeps the cluster size at 32k, but allows the cluster count to rise above 2 million and allows it to reach the oft-quoted 4 million value. It's not clear to me what DOS format does if it's dealing with a volume larger than 128 gb. Some drive makers (like Seagate and Western Digital, maybe others) offer a version of Ontrack Disc Manager for free download that is customized to work only on their brands of hard drives. This software (which frequently crashes when I use it) allows you to set a custom cluster size and will format the drive accordingly. This allows you to create FAT-32 volumes that are not limited by the DOS format's tendency to increase the cluster size on large volumes. The more clusters you have, the longer it takes to compute free disk space under DOS, and you will also see a delay when you browse your drives the first time in a Win-98 session. > the 8G limit as 4k clusters are particularly > desirable for paging to disk. It should be completely possible (and completely compatible with scandisk and defrag) to create a FAT-32 using 4kb clusters up to 16 gb (not 8 gb) if you use a third-party program like Disc Manager. The 8gb limit you speak of comes from how the format program prevents the cluster count from exceeding 2 million and instead increases the cluster size to compensate. There is no reason why format imposes this 2 million limit, other than perhaps MS was looking at performance issues and didn't want the fat to exceed a certain size way back when the hardware was slower. Fat 32: 512 MB - 8191 MB 4K 8192 MB - 16383 MB 8K 16384 MB - 32767 MB 16K Larger than 32768 MB 32K SignatureRegards Ron Badour, MS MVP for W98 Tips: http://home.satx.rr.com/badour Knowledge Base Info: http://support.microsoft.com/default.aspx?pr=kbinfo >>Cluster size is determined by the partition size rather than the size of >>the [quoted text clipped - 42 lines] > Be easier to use! >>--------------- ---- --- -- - - - - The 16 in FAT16 means that 16 bits are used for each FAT entry. This means there can be 65k FAT entries. Each FAT entry corresponds to one cluster. Therefore, as disk size increases the size of each cluster must increase in order to accommodate the whole partition size within the 65k clusters that FAT16 allows. SignatureJeff Richards MS MVP (Windows - Shell/User) >i have a quick question historical question for FAT: why does the > cluster size go up by a factor of two as the disk size increases by a > factor of 2 when the FAT type reaches 16 bits??? Good, there is the missing piece I was looking for. One might also add to this explanation that 16 bits can only hold a max decimal value of 65,535 (allowing for numeric values of 0 thru 65,535), because 2 raised to the 16th power is 65,536 (but the computer works with binary values, of course, or for our convenience, 0000-FFFF, in hexadecimal) > The 16 in FAT16 means that 16 bits are used for each FAT entry. This means > there can be 65k FAT entries. Each FAT entry corresponds to one cluster. [quoted text clipped - 7 lines] >> cluster size go up by a factor of two as the disk size increases by a >> factor of 2 when the FAT type reaches 16 bits??? > i have a quick question historical question for FAT: why does the > cluster size go up by a factor of two as the disk size increases by a > factor of 2 when the FAT type reaches 16 bits??? To make a long story short, there are only a fixed number of allocation units possible (due to the size of the data used to store that info) to store the data on a hard drive. So, with a larger hard disk, which obviously has the capacity to store many more files (and each file needs at least one allocation unit), the allocation unit size HAS to increase (double), when the disk capacity increases (doubles), in order to keep the number of allocation units the same. Well, I think I've stated this correctly, anyways (someone can correct me if I'm wrong). I think your reference to a larger hard disk is incorrect Bill. It is the partition size that counts. A 200 mb fat 16 partition on a 10 gb hard drive has a 4 kb cluster size as does a 200 mb fat 16 partition on an 80 gb hard drive. I am not about to try to figure out all the stuff said in this thread. I have been working on my taxes all day and my brain is numb from useless numbers that don't make much sense :-) SignatureRegards Ron Badour, MS MVP for W98 Tips: http://home.satx.rr.com/badour Knowledge Base Info: http://support.microsoft.com/default.aspx?pr=kbinfo >> i have a quick question historical question for FAT: why does the >> cluster size go up by a factor of two as the disk size increases by a [quoted text clipped - 14 lines] > if > I'm wrong). . snip > I am not about to try to figure out all the stuff said in this thread. I have > been working on my taxes all day and my brain is numb from useless numbers that > don't make much sense :-) At least you've *got* numbers, Ron! ;-) See, there's a bright side after all..... SignatureGlen Ventura, MS MVP Shell/User, A+ http://dts-l.org/ >>> i have a quick question historical question for FAT: why does the >>> cluster size go up by a factor of two as the disk size increases by a [quoted text clipped - 12 lines] >> Well, I think I've stated this correctly, anyways (someone can correct me if >> I'm wrong). > To make a long story short, there are only a fixed number of > allocation units possible (due to the size of the data used > to store that info) to store the data on a hard drive. Like I've said MANY times here in the past month or two, I have found that (besides scandisk not working) Win-98 works fine with up to 40 million clusters per volume - way beyond the theoretical 4.1 million clusters that's supposed to be the formal limit. >> To make a long story short, there are only a fixed number of >> allocation units possible (due to the size of the data used [quoted text clipped - 4 lines] >million clusters per volume - way beyond the theoretical 4.1 million >clusters that's supposed to be the formal limit. Defrag won't work either. Ron Martell Duncan B.C. Canada SignatureMicrosoft MVP (1997 - 2006) On-Line Help Computer Service http://onlinehelp.bc.ca Syberfix Remote Computer Repair "Anyone who thinks that they are too small to make a difference has never been in bed with a mosquito." > > Like I've said MANY times here in the past month or two, I have > > found that (besides scandisk not working) Win-98 works fine with > > up to 40 million clusters per volume - way beyond the theoretical > > 4.1 million clusters that's supposed to be the formal limit. > > Defrag won't work either. Yea, I think I tried that too, and it kacked with some error. But I mostly use Norton utilities (circa 2002 NSW version) for disk stuff, including norton speed disk. I should try that some time and see if it works or not. I know that Norton Ghost 2003 can copy FAT-32 volumes with up to 8 million clusters, but not volumes with 32 million. So again I'm not sure where it's limit is. To continue this issue of whether or not the often quoted 4.177 million cluster limit for FAT-32 is real, I can confirm that Fdisk/Format uses 16kb cluster size at up to volumes with 32 gb in size, resulting in a little over 2 million clusters. If the volume is 33 gb, then a change to 32kb cluster size happens. If max clusters really was 4.1 million, then we'd have 4 kb cluster size at up to 16 gb volumes, then 17gb to 32gb would be using 8kb, then 33gb to 64gb would be 16kb, then 65gb to 128gb would be 32kb. But instead, fdisk/format likes to keep the number of clusters from exceeding 2 million until you hit volume size of 33gb, at which point it lets the cluster count exceed 2 million and probably rise to the 4 million number when the volume hits 64 gb. Again, what determines cluster size - fdisk or format? >> > Like I've said MANY times here in the past month or two, I have >> > found that (besides scandisk not working) Win-98 works fine with [quoted text clipped - 29 lines] > > Again, what determines cluster size - fdisk or format? Format does. Fdisk only creates the partition boundaries and type. Cluster information is located in the boot sector (written during format). > > Again, what determines cluster size - fdisk or format? > > Format does. Fdisk only creates the partition boundaries and > type. Cluster information is located in the boot sector > (written during format). Ok, so why does Format have this reluctance to generate volumes that exceed 2 million clusters when the limit is supposedly 4 million? >> > Again, what determines cluster size - fdisk or format? >> [quoted text clipped - 4 lines] > Ok, so why does Format have this reluctance to generate volumes that > exceed 2 million clusters when the limit is supposedly 4 million? <guess> Memory capacity was "small" when the FAT32 spec was on the drawing board. Processors were "slow"..32GB disks seemed a long way off. It also has to work in real mode (16-bit, conventional memory) DOS. </guess> >> > Like I've said MANY times here in the past month or two, I have >> > found that (besides scandisk not working) Win-98 works fine with [quoted text clipped - 8 lines] >stuff, including norton speed disk. I should try that some time and >see if it works or not. I don't believe it will work either. >To continue this issue of whether or not the often quoted 4.177 >million cluster limit for FAT-32 is real, I can confirm that [quoted text clipped - 10 lines] >it lets the cluster count exceed 2 million and probably rise to the 4 >million number when the volume hits 64 gb. Yes. That is correct. Microsoft decided to be conservative with the FAT32 cluster quantities for some reason. I suspect that somebody misunderstood the underlying specs at some point and thought that the 4 million cluster entries was the total size of the FAT, and as there are 2 copies of it that meant only 2 million clusters for each copy. But I have no way of confirming that, and as it happened a dozen or more years ago the true reason is likely never going to be known. >Again, what determines cluster size - fdisk or format? FDISK sets the cluster size initially. You can change this with the format command if you use the /a: parameter with the format command. Use format /? to see the options available with any given version of format as they do vary. For example, the formart version that comes with Windows XP supports the use of a 64K cluster size for FAT32 drives, but this cluster size would probably be incompatible with the 9x versions of Windows. Ron Martell Duncan B.C. Canada SignatureMicrosoft MVP (1997 - 2006) On-Line Help Computer Service http://onlinehelp.bc.ca Syberfix Remote Computer Repair "Anyone who thinks that they are too small to make a difference has never been in bed with a mosquito." > >Again, what determines cluster size - fdisk or format? > > FDISK sets the cluster size initially. You're the first / only one to mention that tid-bit here. The consensus is that format sets the cluster size. > You can change this with the format command if you use > the /a: parameter with the format command. The format.com that comes with win98se (4/23/99) does not list the /a option. > the format that comes with Windows XP supports the use of a > 64K cluster size for FAT32 drives, but this cluster size > would probably be incompatible with the 9x versions of > Windows. Easy enough to test that. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.