If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Memory hold
Jeff Richards wrote:
The maximum partition size for a FAT32 partition with the tools included with W98 is about 32Gb, but tools that allow larger partitions to be created and managed are available. The 137Gb limitation is imposed by the ATA interface. W98 scandisk and defrag *do* have a 127.53GiB or 137GB partition limitation, caused by their 16 bit nature. http://support.microsoft.com/kb/184006/en-us |
#12
|
|||
|
|||
Memory hold
Jeff Richards wrote:
The maximum partition size for a FAT32 partition with the tools included with W98 is about 32Gb Wrong. I'm not sure if, specifically, win-98 (original or first edition) had any specific problem with drives or volumes larger than 32 gb (I highly doubt it), but second edition (and specifically fdisk) is easily capable of formatting drives and volumes at least up to 128 gb in size. There may have been a problem with some versions of fdisk and their ability to format drives or volumes larger than 64 gb. But fdisk is essentially what we're talking about here, and different versions of fdisk did have various problems (some were major, some were minor). Microsoft did provide at least 1 update to fdisk after win-98se was released, perhaps 2. The 32 gb problem you're thinking about is probably the fact that Micro$oft handicapped win-2k and XP (and probably Vista as well) by preventing them from having the ability to create fat32 volumes larger than 32 gb. As far as "management" of large fat32 volumes, specifically the use of DOS scandisk, windows scandisk and defrag, the criteria that determines what their limits are are different, and they center around the number of clusters or allocation units on the volume. Any volume that does not exceed 4 million allocation units will have no problems with windows-98 scandisk or defrag. The DOS scandisk program has no limits as far as I can tell, and I've tested it on drives with up to 120 million clusters. The use of Windows ME versions of scandisk and defrag on win-98 has been found to allow the use of even larger drives (exceeding 4 million clusters). The 137Gb limitation is imposed by the ATA interface. Although it is possible to arrange the partitioning so that a FAT32 partition extends beyond this limit, restrictions in ATA and the Int13 interface means that addresses will wrap around and writes to such a partition will corrupt other parts of the disk. Actually Jeff, that statement is quite wrong. I'm surprised that an MVP would post such incorrect information. It's probably indicative that you spend little to no time using win-98 any more. The truth is that the ATA interface is 48 bits wide, and the BIOS Int13 "enhanced" access routines allow full addressability to the full FAT32 spec. In other words, under DOS, a program (including DOS itself) has full access to the largest FAT32 volume possible - 2.2 tb (terra-bytes). This would be the case for any computer who's motherboard was made, oh, say, during or after 2002. Prior to 2002, many BIOS's did not impliment the full 48 bits, so many older computers will experience a variety of drive-size limits that may be possible to remedy with a BIOS update. With regard specifically to Windows, the specs of the protected-mode IDE driver will determine if Windows has a volume-size or drive-size limitation (not the BIOS or NOT the specs of the ATA interface). Win-2K and XP were both originally limited to 128 gb drive size because of the way their IDE drivers were written. That was corrected later with service packs. In the case of Windows 98, it's protected mode driver (EDSI_506.PDR) is the limiting factor that prevents a "generic" installation of win-98 from being able to use a drive larger than 128 gb. This limitation can be eliminated if a secondary drive controller is installed (it will come with it's own driver which replaces EDSI_506.PDR). There are also third-party direct replacements for ESDI_506.PDR. The use of a SATA hard drive (by installing win-98 on motherboards with SATA interfaces made during 2003 to about 2006) will almost universally, with little effort, allow win-98 to be compatible with pretty much any hard drive available today. The whole system must be configured with 48-bit LBA to use any part of a disk beyond 137Gb in W98. While that sweeping statement is true, it can be said more specifically that the protected mode driver that win-98 uses for hard-drive access must adhere to the full 48-bit IDE/ATA standard. One way to do this, if the user is really in a bind and has no other choices, is to simply rename the file ESDI_506.PDR to something else so that win-98 doesn't have access to it and can't load it. In that case, win-98 will resort to "compatibility-mode" or "dos-mode" hard-drive access, in which case it will use the bios routines to access the drive, which will be be perfectly fine so long as the BIOS has also implimented 48-bit addressing. This will result in slower / lower performance while using win-98, however. |
#13
|
|||
|
|||
Memory hold
Jeff Richards wrote:
The maximum partition size for a FAT32 partition with the tools included with W98 is about 32Gb Wrong. I'm not sure if, specifically, win-98 (original or first edition) had any specific problem with drives or volumes larger than 32 gb (I highly doubt it), but second edition (and specifically fdisk) is easily capable of formatting drives and volumes at least up to 128 gb in size. There may have been a problem with some versions of fdisk and their ability to format drives or volumes larger than 64 gb. But fdisk is essentially what we're talking about here, and different versions of fdisk did have various problems (some were major, some were minor). Microsoft did provide at least 1 update to fdisk after win-98se was released, perhaps 2. The 32 gb problem you're thinking about is probably the fact that Micro$oft handicapped win-2k and XP (and probably Vista as well) by preventing them from having the ability to create fat32 volumes larger than 32 gb. As far as "management" of large fat32 volumes, specifically the use of DOS scandisk, windows scandisk and defrag, the criteria that determines what their limits are are different, and they center around the number of clusters or allocation units on the volume. Any volume that does not exceed 4 million allocation units will have no problems with windows-98 scandisk or defrag. The DOS scandisk program has no limits as far as I can tell, and I've tested it on drives with up to 120 million clusters. The use of Windows ME versions of scandisk and defrag on win-98 has been found to allow the use of even larger drives (exceeding 4 million clusters). The 137Gb limitation is imposed by the ATA interface. Although it is possible to arrange the partitioning so that a FAT32 partition extends beyond this limit, restrictions in ATA and the Int13 interface means that addresses will wrap around and writes to such a partition will corrupt other parts of the disk. Actually Jeff, that statement is quite wrong. I'm surprised that an MVP would post such incorrect information. It's probably indicative that you spend little to no time using win-98 any more. The truth is that the ATA interface is 48 bits wide, and the BIOS Int13 "enhanced" access routines allow full addressability to the full FAT32 spec. In other words, under DOS, a program (including DOS itself) has full access to the largest FAT32 volume possible - 2.2 tb (terra-bytes). This would be the case for any computer who's motherboard was made, oh, say, during or after 2002. Prior to 2002, many BIOS's did not impliment the full 48 bits, so many older computers will experience a variety of drive-size limits that may be possible to remedy with a BIOS update. With regard specifically to Windows, the specs of the protected-mode IDE driver will determine if Windows has a volume-size or drive-size limitation (not the BIOS or NOT the specs of the ATA interface). Win-2K and XP were both originally limited to 128 gb drive size because of the way their IDE drivers were written. That was corrected later with service packs. In the case of Windows 98, it's protected mode driver (EDSI_506.PDR) is the limiting factor that prevents a "generic" installation of win-98 from being able to use a drive larger than 128 gb. This limitation can be eliminated if a secondary drive controller is installed (it will come with it's own driver which replaces EDSI_506.PDR). There are also third-party direct replacements for ESDI_506.PDR. The use of a SATA hard drive (by installing win-98 on motherboards with SATA interfaces made during 2003 to about 2006) will almost universally, with little effort, allow win-98 to be compatible with pretty much any hard drive available today. The whole system must be configured with 48-bit LBA to use any part of a disk beyond 137Gb in W98. While that sweeping statement is true, it can be said more specifically that the protected mode driver that win-98 uses for hard-drive access must adhere to the full 48-bit IDE/ATA standard. One way to do this, if the user is really in a bind and has no other choices, is to simply rename the file ESDI_506.PDR to something else so that win-98 doesn't have access to it and can't load it. In that case, win-98 will resort to "compatibility-mode" or "dos-mode" hard-drive access, in which case it will use the bios routines to access the drive, which will be be perfectly fine so long as the BIOS has also implimented 48-bit addressing. This will result in slower / lower performance while using win-98, however. |
#14
|
|||
|
|||
Memory hold
|
#15
|
|||
|
|||
Memory hold
|
#16
|
|||
|
|||
Memory hold
Ingeborg wrote:
The 137Gb limitation is imposed by the ATA interface. W98 scandisk and defrag *do* have a 127.53GiB or 137GB partition limitation, caused by their 16 bit nature. http://support.microsoft.com/kb/184006/en-us The real problem for win-98 scandisk and defrag is win-98's IDE driver - ESDI_506.PDR. It does not allow correct access beyond the 128 gb point on the drive. Microsoft carefully words their explaination to point the blame at scandisk and defrag being 16 bits instead of their own failing for updating ESDI_506.PDR to the full 48 bits (like they had to do for 2K and XP). With regard to win-98 scandisk and defrag, the answer is to simply use the win-me versions of those apps (they allow for the use of volumes with much higher cluster-count values). They also say in other kb's that DOS scandisk is also a 16-bit program and is not compatible with drives with more than 4 million clusters, but I've found that to be an outright lie. I suggest anyone wanting to understand these limitations in more detail look at these: http://tinyurl.com/ch8935 http://tinyurl.com/cm75pf Reposted below is the majority of material contained in the above 2 links: ----------------------------- Newsgroups: microsoft.public.win98.gen_discussion From: 98 Guy Date: Mon, 26 Feb 2007 10:49:46 -0500 Subject: Update 4: Cluster size and exploring the limits of FAT-32 I think this will be the last update, as I've made a rather important discovery, which is that DOS scandisk (both the original win-98 version and the windows ME version) don't really seem to have a cluster size limitation. Specifically, here's what I've just tested: drive c: 25 gb / 4kb cluster size / 6.3 million clusters drive d: 31 gb / 4kb cluster size / 7.8 million clusters drive e: 125 gb / 4kb cluster size / 31.2 million clusters drive f: 156 gb / 32kb cluster size / 4.9 million clusters drive (c) is SATA drive 1 drive (d) and (e) are SATA drive 2 drive (f) is SATA drive 3 Drive C has win-98se installed, and instead of starting 98 I instead brought up the start menu and started in DOS. From the command prompt, I ran scandisk (Win-98se and Win-ME). Both of them ran fine on all of the above volumes. Previously when I was testing dos scandisk.exe, I was booting from a floppy, and probably wasn't loading himem.sys. Himem.sys is needed by scandisk to run properly. So here is the master summary of this thread: --------------------------- 1) Scandisk (DOS scandisk.exe, not Windows scandskw.exe) does not appear to have a cluster-count limitation. Both Win-98se and Win-ME versions of scandisk have been run on drives with up to 31 million clusters and have executed properly with no errors. Himem.sys must be loaded for scandisk to function properly. Microsoft states that FAT-32 volumes are limited to 4.17 million clusters because of scandisk.exe, and that scandisk.exe is limited to a memory or data array size of 16 million bytes. It could very well be that this 16 mb limit is based on Microsoft's stated minimum system requirements for Windows 98 (which is 16 mb of system RAM) and that scandisk will automatically make use of all available system memory if required. ---------------------------- 2) Win-98se has been installed directly on 160 gb volumes formatted with 4kb cluster size (resulting in 40 million clusters) and has not shown any instability. This was performed on a 160 gb SATA drive assigned to a RAID controller (but not used in RAID mode). To test for 137gb data corruption (which theoretically takes place when a read or write across the 137 gb boundary occurrs) a series of 1 gb VOB files were copied repeatedly in order to fill the drive. The drive was eventually filled with 150 of these 1 gb files, and no drive corruption occurred. ---------------------------- 3) The only drawback that I've seen when running a volume with a large cluster count is that DOS will take a much longer time to perform the first DIR command. This might also happen in Windows as well - I may have seen this effect but I haven't specifically looked for it. The issue is the computation and display of free remaining drive space, which is part of the DIR command and also happens when browsing the drives in windows. Related to this is the question does windows store the amount of remaining drive space somewhere on the drive (instead of requiring it to be re-calculated every time it's needed). --------------------------- 4) Standard DOS tools like fdisk and format can be used to partition and format hard drives in excess of 137 gb. Fdisk was used to partition a 160 gb drive into a 32 gb primary and 121 gb secondary. The updated or "fixed" version of fdisk.exe was used. What has not been tested (yet) is the undocumented /Z:n command line parameter for format, which allows the user to specify a particular cluster size (n x 512 bytes). Third-party drive utilities (based on On Track's Disc Manager) can also be used to partition and format hard drives, but I have found those utilities to be very unstable and to lock up/crash about 75% of the time I use them. --------------------------- 5) There is evidence that 6,291,204 clusters may represent some sort of "magic number". A third-party drive partition tool (PartitionMagic Pro Server 8.05) resorted to this cluster count when an existing 32 gb partition was manually resized to 4kb cluster size. Norton Disk Doctor and Speed Disk was found to work properly using this cluster count, but not on a volume with a slightly larger cluster count of 7.8 million clusters (see note 7 below). This 6.3 million cluster count, combined with 32kb cluster size, results in a volume size of 206 gb. Perhaps this set of parameters is the reason for the 200 gb hard drive size which emerged in early to mid 2003. A dir command is also performed instantly with no delays in computing free space given a volume with 6.3 million clusters. --------------------------- 6) Win-98 versions of Scandisk (scandskw.exe) and Defrag did not function on a volume with 6.3 million clusters but seems to be limited to the MS stated value of 4.17 clusters. However, Windows ME versions of dskmaint.dll and defrag.exe does appear to function correctly with Windows 98se and compatibility with volume size of up to 31.2 million clusters has been observed. It is not know what their ultimate limit is. ---------------------------- 7) Norton Utilities is a very common third-party set of applications and their compatibility with large hard drives with a large cluster count may be of importance to some people. I have found that Norton Disk Doctor and Norton Speed disk were compatible with volumes with up to 6.3 million clusters, but not more without using the command-line parameter /NOLBA. When using this parameter, NDD and SD worked on volumes with 7.8 million clusters but not 31 million. The exact cluster-count limit is therefore unknown at this point and I may explore that in the future. The switch /NOLBA forces NDD and SD to skip the drive configuration check. This can also be done using a registry entry by adding a DWORD registry value named NOLBACHECK at this location: HKEY_LOCAL_MACHINE\Software\Symantec\Norton Utilities When this option is set to 1, Norton Disk Doctor and Speed Disk skip the drive configuration check. ---------------------------- 8) Anyone considering adding a large hard drive (a drive larger than 137 gb) to an existing win-98 computer needs to consider certain issues that include the drive type (IDE/PATA vs SATA) as well as how the drive is controlled by the motherboard BIOS (mapped to IDE channel or controlled by RAID controller). The main issue here is that you DO NOT WANT the win-98se 32-bit driver (ESDI_506.PDR) to be used to access a hard drive larger than 137 gb. Many or most motherboards made for the past 3 years will have built-in SATA ports. Windows-98 users are advised to obtain SATA drives instead of the older conventional IDE drives when adding a new drive (larger than 137 gb) to a system or if building a new system. ------------------------------ Newsgroups: microsoft.public.win98.gen_discussion, microsoft.public.win98.disks.general, alt.windows98 From: 98 Guy Date: Mon, 23 Jul 2007 19:15:57 -0400 Local: Mon, Jul 23 2007 7:15 pm Subject: Windows 98 large file-count tests on large volume (500 gb hard drive) File copy test - Windows 98 ------------------------- Hardware Details: Motherboard: ASRock Dual VSTA: http://www.asrock.com/mb/overview.as...l=775Dual-vsta CPU: Intel Celeron 3.46 ghz Chipset: VIA PT880 Pro/Ultra Chipset Driver download (VIA Hyperion Pro Driver Package): http://www.viaarena.com/Driver/VIA_H...nPro_V512A.zip Onboard lan: Via Rhine II / Lan driver: fetnd5av.sys http://www.viaarena.com/Driver/VT610...235_VT8237_VT8... Installed memory: 512 mb, DDR USB 2.0 Root Hub (driver: usbhub20.sys) VIA PCI to USB Enhanced Host Controller (driver: usbehci.sys) http://www.viaarena.com/Driver/VIA_USB2_V270p1-L-M.zip Hard drive: Western Digital WD5000KS (500 gb) SATA Hard drive is controlled by on-board VIA VT8237A Raid controller (viamraid.mpd, ios.vxd, viamvsd.vxd) ------------------------- Windows-98se CD was copied to it's own directory on the hard drive, and all cab files were unpacked into their own separate subdirectory. In addition to the unpacked cabs, I copied all files in my win-98 system and system32 directories. So this sub-directory has 2000 files (129 mb). The over-all size of the win-CD directory is therefore 767 mb (5565 files, 366 folders). I replicated that directory 541 times in a tree as follows: c:\file test (root test directory) \Super-1 \Super-2 \Super-3 In each of the above three directories, 10 subdirectories (0001 through 0010). In each of those 10 directories, 18 subdirectories (000A through 000R). In each of those, a copy of the above-described win98-CD source files. The file-properties dialog box for c:\file test takes 10 to 15 minutes to arrive at a final tally, which is: Size: 405 gb (435,633,783 bytes) 441,899,741,184 Contains: 3,010,665 Files, 199,119 Folder Screen capture of file-properties dialog box: http://www.fileden.com/files/2007/5/.../file-test.jpg (that is no longer a functional link) Based on the size (135 gb) and time-stamps of the Super-x directories, I calculated that the file-copy rate was effectively 11.5 mb per second (it took 3.5 hours to copy the contents of Super-1 to Super-2). chkdsk c: 487,431,968 kilobytes total disk space 52,323,392 kilobytes free 4096 bytes in each allocation unit 121,857,992 total allocation units on disk 13,080,848 available allocation units on disk I re-started the computer in DOS and ran DOS-scandisk. I left it running, will check back in a few hours to see how it finished. Conclusion / Comments: Well, basically, I almost filled a 500 gb hard drive with a replicated set of files that range in size from a few bytes to a few mb in size. A grand total of over 3 million files spread across almost 200,000 directories. Windows was functional during and after this file-copy process, and the system continues to boot and function normally. If anyone out there is not satisfied that my test methodology was not sufficient to correctly test win-98 for a file-count limitation or a directory-size limitation that may arise given current modern large hard drives available today, please speak up and describe an alternate test method. As a comment, I don't believe that creating a set of zero-byte files will necessarily accomplish or test windows-98 with the same level of "stress" as the test I describe here. --------------------------- The drive in question was formatted with Western Digital "Data Lifeguard Tools" version 11.2 for DOS: http://support.wdc.com/download/downloadxml.asp#53 http://websupport.wdc.com/rd.asp?p=s...http://support... It creates a bootable floppy with drive-formatting software (I believe it's some version of OnTrack's Disk Manager software). It allows for the quick partioning and formatting of WD drives. For FAT-32, it allows the user to choose the cluster size, from 512 bytes up to 32 kb. I don't think there is a specific directory size (number of entries) limitation, except in the root directory. Actually, I think that FAT and FAT-16 had a limit of something like 512 entries in the root directory (I remember some win-95 systems that didn't work properly when the number of files in the root directory reached 512). I believe I read somewhere that FAT-32 does not allocate a fixed size for the directory hence there is no practical limitation as to how many entries the directory (root or otherwise) can contain. ----------- Just a bit of an update regarding DOS scandisk and my 500 gb drive. After approx. 24 hours, scandisk is still operating on the drive. Within the first few minutes (perhaps the first 15 - 30 minutes) it checked the Media Descriptor and the File Allocation Tables. What has taken the majority of time so far is the check of the Directory Structure. It is currently at the 24% point of that check. I'll let it go over night and see where it's at in the morning. -------------- Ok, there seems to be a problem with enabling virtual memory. From the System Properties, Performance tab, I am told that virtual memory is not enabled. When I bring up the virtual memory dialog box, the radio-button "let windows manage my virtual memory settings" is selected, and the following information is shown in grey: Hard Disk: c:\ -14440 MB Free Minumum: 0 Maximum: no maximum When I select the radio button "Let me specify my own virtual memory settings" those settings change to this: Hard Disk: c:\-14440 MB Free Minimum: 0 Maximum: 51096 I changed the maximum to 512 (I assume that's mega-bytes) and restarted. Virtual memory was still showing as being disabled. I set both the min and max to be 512 and restarted again. It still said that virtual memory was disabled, but this time the Hard Disk value had changed to -13928 MB Free (a difference of 512). I changed both to 128 and still virtual memory was still disabled. Prior to each change, I looked for win386.swp in the root directory, but it was never there (even when I tried to unhide it using attrib). So something wierd is going on with the swap file and virtual memory. Might have to resort to messing with registry or .ini settings to see if I can get it going. Any known issues with Win-98 showing a negative number for hard drive space or otherwise for refusing to enable the swap file? ------------------ PS I have always been told the problem of large number of clusters in 98 was due to the fact that on boot the FAT Table was read into memory and would use up all available memory just to hold the FAT Table. That argument was offered back last February when I first tried running win-98 on fat-32 volumes with large cluster counts. I countered by pointing out that by Microsoft's own reasoning, a volume was never allowed to have more than 4.177 million clusters because that was the largest number of clusters that DOS scandisk could process given a supposed 16 mb array size limitation. They mentioned nothing about windows needing to load the entire FAT table during normal use. And besides, given Win98's specified minimum requirements (16 mb ram), you'd have a situation where a good chunk of that would have been consumed by the FAT. I've since discovered that DOS scandisk has no such 16 mb memory limitation. Or perhaps it does, but it doesn't effect it's ability to process a FAT with more than 4 million clusters. I think that the only time the entire FAT table is read into system memory is during disk maintainence like Windows scandisk and defrag. If it's true that you need 4 bytes per cluster to read in the FAT table, then maybe if I put more memory into the system the windows-ME versions of scandisk and defrag would work. I think I'll try that. If this were true it seems that with your 500G test all available memory would be used and there would be nothing left for programs. Yes, that would have to be the case given 121 million clusters in my situation (with 512 mb installed memory). It also seems that your boot times would be in minutes not seconds just to read the FAT Table. The system boots fast, certainly within 1 minute. I haven't timed it yet. -------------------- Franc Zabkar wrote: Is this it? Negative Hard Disk Free Size Reported on Virtual Memory Tab in System Properties: http://support.microsoft.com/kb/272620 As reported he http://support.microsoft.com/kb/272620 I obtained the updated file from the win-98 service-pack thing (unpacked it manually) and replaced my existing sysdm.cpl. While it did correct the display of a negative free size on the hard drive, it did not solve the virtual memory issue. I then connected another SATA drive to the system (160 gb, with a single 25 gb FAT-32 partition, formatted with 4 kb clusters, a little over 6 million clusters) and Win-98 DID enable virtual memory when instructed to put the swap file on the new drive. So for some reason win-98 did not want to locate the swap file on the 500 gb drive. Either it did not like the fact that the drive was formatted with 4kb cluster size (resulting in 121 million clusters) or it didn't like where on the drive it would have to put it (at the back 10% of the drive). Also - I increased the amount of installed memory to 1 gb, and still got "insufficient memory" when running Windows Scandisk and Defrag on the 500 gb drive. DOS scandisk does not give an error, but it would have taken 4 days to run (given it was at the 30% point after 30 hours). -------------- July 28, 2007 Ron Martell wrote: The FAT32 implementation provides for 28 bits to be used for cluster numbers, which means that it is possible to have up to 268,435,445 total clusters on a drive. Smaller limitations are the result of the tools (FDISK & Format for example) normally used to create FAT32 drives. There is little to no information regarding Win-98's compatibility or operational stability with volumes with large cluster-counts, and just what gets broken at what cluster-count. The year-2000 update to fdisk does work for 250 gb drives (I haven't tried it on a 500 gb drive). Format also works on 250 gb drives, but because of it's use of 32kb cluster size there will be 7.6 million clusters on a 250 gb drive. I am not sure if the native win-98 versions of scandskw.exe, dskmaint.dll and defrag.exe will operate on a volume that exceeds 4.17 million clusters but the win-me versions will, at least up to 31 million clusters. The windows ME versions did not function on a volume with 121 million clusters, displaying an "insufficient memory" message (even on a system with 1 gb memory). The MS-DOS version of scandisk.exe does not seem to have a cluster-count limitation and has been seen to run without issue even on a 500 gb drive with 121 million clusters (although it was only allowed to run for 30 hours before being terminated - it was projected that it would have taken 3 more days to complete it's scan). It has been speculated that the number of clusters is limited because win-98 loads the entire FAT table into memory during normal operational use, but given the recent test with a 121-million cluster drive that theory appears to be wrong. The only issue so far with win-98 installed on a 500 gb volume with 121 million clusters is that it will not create or place the swap file on it, hence virtual memory will not be enabled. It will create / place the swap file on a secondary drive, even if that drive is another 500 gb drive (but formatted with 32kb cluster size resulting in 15 million clusters). |
#17
|
|||
|
|||
Memory hold
Ingeborg wrote:
The 137Gb limitation is imposed by the ATA interface. W98 scandisk and defrag *do* have a 127.53GiB or 137GB partition limitation, caused by their 16 bit nature. http://support.microsoft.com/kb/184006/en-us The real problem for win-98 scandisk and defrag is win-98's IDE driver - ESDI_506.PDR. It does not allow correct access beyond the 128 gb point on the drive. Microsoft carefully words their explaination to point the blame at scandisk and defrag being 16 bits instead of their own failing for updating ESDI_506.PDR to the full 48 bits (like they had to do for 2K and XP). With regard to win-98 scandisk and defrag, the answer is to simply use the win-me versions of those apps (they allow for the use of volumes with much higher cluster-count values). They also say in other kb's that DOS scandisk is also a 16-bit program and is not compatible with drives with more than 4 million clusters, but I've found that to be an outright lie. I suggest anyone wanting to understand these limitations in more detail look at these: http://tinyurl.com/ch8935 http://tinyurl.com/cm75pf Reposted below is the majority of material contained in the above 2 links: ----------------------------- Newsgroups: microsoft.public.win98.gen_discussion From: 98 Guy Date: Mon, 26 Feb 2007 10:49:46 -0500 Subject: Update 4: Cluster size and exploring the limits of FAT-32 I think this will be the last update, as I've made a rather important discovery, which is that DOS scandisk (both the original win-98 version and the windows ME version) don't really seem to have a cluster size limitation. Specifically, here's what I've just tested: drive c: 25 gb / 4kb cluster size / 6.3 million clusters drive d: 31 gb / 4kb cluster size / 7.8 million clusters drive e: 125 gb / 4kb cluster size / 31.2 million clusters drive f: 156 gb / 32kb cluster size / 4.9 million clusters drive (c) is SATA drive 1 drive (d) and (e) are SATA drive 2 drive (f) is SATA drive 3 Drive C has win-98se installed, and instead of starting 98 I instead brought up the start menu and started in DOS. From the command prompt, I ran scandisk (Win-98se and Win-ME). Both of them ran fine on all of the above volumes. Previously when I was testing dos scandisk.exe, I was booting from a floppy, and probably wasn't loading himem.sys. Himem.sys is needed by scandisk to run properly. So here is the master summary of this thread: --------------------------- 1) Scandisk (DOS scandisk.exe, not Windows scandskw.exe) does not appear to have a cluster-count limitation. Both Win-98se and Win-ME versions of scandisk have been run on drives with up to 31 million clusters and have executed properly with no errors. Himem.sys must be loaded for scandisk to function properly. Microsoft states that FAT-32 volumes are limited to 4.17 million clusters because of scandisk.exe, and that scandisk.exe is limited to a memory or data array size of 16 million bytes. It could very well be that this 16 mb limit is based on Microsoft's stated minimum system requirements for Windows 98 (which is 16 mb of system RAM) and that scandisk will automatically make use of all available system memory if required. ---------------------------- 2) Win-98se has been installed directly on 160 gb volumes formatted with 4kb cluster size (resulting in 40 million clusters) and has not shown any instability. This was performed on a 160 gb SATA drive assigned to a RAID controller (but not used in RAID mode). To test for 137gb data corruption (which theoretically takes place when a read or write across the 137 gb boundary occurrs) a series of 1 gb VOB files were copied repeatedly in order to fill the drive. The drive was eventually filled with 150 of these 1 gb files, and no drive corruption occurred. ---------------------------- 3) The only drawback that I've seen when running a volume with a large cluster count is that DOS will take a much longer time to perform the first DIR command. This might also happen in Windows as well - I may have seen this effect but I haven't specifically looked for it. The issue is the computation and display of free remaining drive space, which is part of the DIR command and also happens when browsing the drives in windows. Related to this is the question does windows store the amount of remaining drive space somewhere on the drive (instead of requiring it to be re-calculated every time it's needed). --------------------------- 4) Standard DOS tools like fdisk and format can be used to partition and format hard drives in excess of 137 gb. Fdisk was used to partition a 160 gb drive into a 32 gb primary and 121 gb secondary. The updated or "fixed" version of fdisk.exe was used. What has not been tested (yet) is the undocumented /Z:n command line parameter for format, which allows the user to specify a particular cluster size (n x 512 bytes). Third-party drive utilities (based on On Track's Disc Manager) can also be used to partition and format hard drives, but I have found those utilities to be very unstable and to lock up/crash about 75% of the time I use them. --------------------------- 5) There is evidence that 6,291,204 clusters may represent some sort of "magic number". A third-party drive partition tool (PartitionMagic Pro Server 8.05) resorted to this cluster count when an existing 32 gb partition was manually resized to 4kb cluster size. Norton Disk Doctor and Speed Disk was found to work properly using this cluster count, but not on a volume with a slightly larger cluster count of 7.8 million clusters (see note 7 below). This 6.3 million cluster count, combined with 32kb cluster size, results in a volume size of 206 gb. Perhaps this set of parameters is the reason for the 200 gb hard drive size which emerged in early to mid 2003. A dir command is also performed instantly with no delays in computing free space given a volume with 6.3 million clusters. --------------------------- 6) Win-98 versions of Scandisk (scandskw.exe) and Defrag did not function on a volume with 6.3 million clusters but seems to be limited to the MS stated value of 4.17 clusters. However, Windows ME versions of dskmaint.dll and defrag.exe does appear to function correctly with Windows 98se and compatibility with volume size of up to 31.2 million clusters has been observed. It is not know what their ultimate limit is. ---------------------------- 7) Norton Utilities is a very common third-party set of applications and their compatibility with large hard drives with a large cluster count may be of importance to some people. I have found that Norton Disk Doctor and Norton Speed disk were compatible with volumes with up to 6.3 million clusters, but not more without using the command-line parameter /NOLBA. When using this parameter, NDD and SD worked on volumes with 7.8 million clusters but not 31 million. The exact cluster-count limit is therefore unknown at this point and I may explore that in the future. The switch /NOLBA forces NDD and SD to skip the drive configuration check. This can also be done using a registry entry by adding a DWORD registry value named NOLBACHECK at this location: HKEY_LOCAL_MACHINE\Software\Symantec\Norton Utilities When this option is set to 1, Norton Disk Doctor and Speed Disk skip the drive configuration check. ---------------------------- 8) Anyone considering adding a large hard drive (a drive larger than 137 gb) to an existing win-98 computer needs to consider certain issues that include the drive type (IDE/PATA vs SATA) as well as how the drive is controlled by the motherboard BIOS (mapped to IDE channel or controlled by RAID controller). The main issue here is that you DO NOT WANT the win-98se 32-bit driver (ESDI_506.PDR) to be used to access a hard drive larger than 137 gb. Many or most motherboards made for the past 3 years will have built-in SATA ports. Windows-98 users are advised to obtain SATA drives instead of the older conventional IDE drives when adding a new drive (larger than 137 gb) to a system or if building a new system. ------------------------------ Newsgroups: microsoft.public.win98.gen_discussion, microsoft.public.win98.disks.general, alt.windows98 From: 98 Guy Date: Mon, 23 Jul 2007 19:15:57 -0400 Local: Mon, Jul 23 2007 7:15 pm Subject: Windows 98 large file-count tests on large volume (500 gb hard drive) File copy test - Windows 98 ------------------------- Hardware Details: Motherboard: ASRock Dual VSTA: http://www.asrock.com/mb/overview.as...l=775Dual-vsta CPU: Intel Celeron 3.46 ghz Chipset: VIA PT880 Pro/Ultra Chipset Driver download (VIA Hyperion Pro Driver Package): http://www.viaarena.com/Driver/VIA_H...nPro_V512A.zip Onboard lan: Via Rhine II / Lan driver: fetnd5av.sys http://www.viaarena.com/Driver/VT610...235_VT8237_VT8... Installed memory: 512 mb, DDR USB 2.0 Root Hub (driver: usbhub20.sys) VIA PCI to USB Enhanced Host Controller (driver: usbehci.sys) http://www.viaarena.com/Driver/VIA_USB2_V270p1-L-M.zip Hard drive: Western Digital WD5000KS (500 gb) SATA Hard drive is controlled by on-board VIA VT8237A Raid controller (viamraid.mpd, ios.vxd, viamvsd.vxd) ------------------------- Windows-98se CD was copied to it's own directory on the hard drive, and all cab files were unpacked into their own separate subdirectory. In addition to the unpacked cabs, I copied all files in my win-98 system and system32 directories. So this sub-directory has 2000 files (129 mb). The over-all size of the win-CD directory is therefore 767 mb (5565 files, 366 folders). I replicated that directory 541 times in a tree as follows: c:\file test (root test directory) \Super-1 \Super-2 \Super-3 In each of the above three directories, 10 subdirectories (0001 through 0010). In each of those 10 directories, 18 subdirectories (000A through 000R). In each of those, a copy of the above-described win98-CD source files. The file-properties dialog box for c:\file test takes 10 to 15 minutes to arrive at a final tally, which is: Size: 405 gb (435,633,783 bytes) 441,899,741,184 Contains: 3,010,665 Files, 199,119 Folder Screen capture of file-properties dialog box: http://www.fileden.com/files/2007/5/.../file-test.jpg (that is no longer a functional link) Based on the size (135 gb) and time-stamps of the Super-x directories, I calculated that the file-copy rate was effectively 11.5 mb per second (it took 3.5 hours to copy the contents of Super-1 to Super-2). chkdsk c: 487,431,968 kilobytes total disk space 52,323,392 kilobytes free 4096 bytes in each allocation unit 121,857,992 total allocation units on disk 13,080,848 available allocation units on disk I re-started the computer in DOS and ran DOS-scandisk. I left it running, will check back in a few hours to see how it finished. Conclusion / Comments: Well, basically, I almost filled a 500 gb hard drive with a replicated set of files that range in size from a few bytes to a few mb in size. A grand total of over 3 million files spread across almost 200,000 directories. Windows was functional during and after this file-copy process, and the system continues to boot and function normally. If anyone out there is not satisfied that my test methodology was not sufficient to correctly test win-98 for a file-count limitation or a directory-size limitation that may arise given current modern large hard drives available today, please speak up and describe an alternate test method. As a comment, I don't believe that creating a set of zero-byte files will necessarily accomplish or test windows-98 with the same level of "stress" as the test I describe here. --------------------------- The drive in question was formatted with Western Digital "Data Lifeguard Tools" version 11.2 for DOS: http://support.wdc.com/download/downloadxml.asp#53 http://websupport.wdc.com/rd.asp?p=s...http://support... It creates a bootable floppy with drive-formatting software (I believe it's some version of OnTrack's Disk Manager software). It allows for the quick partioning and formatting of WD drives. For FAT-32, it allows the user to choose the cluster size, from 512 bytes up to 32 kb. I don't think there is a specific directory size (number of entries) limitation, except in the root directory. Actually, I think that FAT and FAT-16 had a limit of something like 512 entries in the root directory (I remember some win-95 systems that didn't work properly when the number of files in the root directory reached 512). I believe I read somewhere that FAT-32 does not allocate a fixed size for the directory hence there is no practical limitation as to how many entries the directory (root or otherwise) can contain. ----------- Just a bit of an update regarding DOS scandisk and my 500 gb drive. After approx. 24 hours, scandisk is still operating on the drive. Within the first few minutes (perhaps the first 15 - 30 minutes) it checked the Media Descriptor and the File Allocation Tables. What has taken the majority of time so far is the check of the Directory Structure. It is currently at the 24% point of that check. I'll let it go over night and see where it's at in the morning. -------------- Ok, there seems to be a problem with enabling virtual memory. From the System Properties, Performance tab, I am told that virtual memory is not enabled. When I bring up the virtual memory dialog box, the radio-button "let windows manage my virtual memory settings" is selected, and the following information is shown in grey: Hard Disk: c:\ -14440 MB Free Minumum: 0 Maximum: no maximum When I select the radio button "Let me specify my own virtual memory settings" those settings change to this: Hard Disk: c:\-14440 MB Free Minimum: 0 Maximum: 51096 I changed the maximum to 512 (I assume that's mega-bytes) and restarted. Virtual memory was still showing as being disabled. I set both the min and max to be 512 and restarted again. It still said that virtual memory was disabled, but this time the Hard Disk value had changed to -13928 MB Free (a difference of 512). I changed both to 128 and still virtual memory was still disabled. Prior to each change, I looked for win386.swp in the root directory, but it was never there (even when I tried to unhide it using attrib). So something wierd is going on with the swap file and virtual memory. Might have to resort to messing with registry or .ini settings to see if I can get it going. Any known issues with Win-98 showing a negative number for hard drive space or otherwise for refusing to enable the swap file? ------------------ PS I have always been told the problem of large number of clusters in 98 was due to the fact that on boot the FAT Table was read into memory and would use up all available memory just to hold the FAT Table. That argument was offered back last February when I first tried running win-98 on fat-32 volumes with large cluster counts. I countered by pointing out that by Microsoft's own reasoning, a volume was never allowed to have more than 4.177 million clusters because that was the largest number of clusters that DOS scandisk could process given a supposed 16 mb array size limitation. They mentioned nothing about windows needing to load the entire FAT table during normal use. And besides, given Win98's specified minimum requirements (16 mb ram), you'd have a situation where a good chunk of that would have been consumed by the FAT. I've since discovered that DOS scandisk has no such 16 mb memory limitation. Or perhaps it does, but it doesn't effect it's ability to process a FAT with more than 4 million clusters. I think that the only time the entire FAT table is read into system memory is during disk maintainence like Windows scandisk and defrag. If it's true that you need 4 bytes per cluster to read in the FAT table, then maybe if I put more memory into the system the windows-ME versions of scandisk and defrag would work. I think I'll try that. If this were true it seems that with your 500G test all available memory would be used and there would be nothing left for programs. Yes, that would have to be the case given 121 million clusters in my situation (with 512 mb installed memory). It also seems that your boot times would be in minutes not seconds just to read the FAT Table. The system boots fast, certainly within 1 minute. I haven't timed it yet. -------------------- Franc Zabkar wrote: Is this it? Negative Hard Disk Free Size Reported on Virtual Memory Tab in System Properties: http://support.microsoft.com/kb/272620 As reported he http://support.microsoft.com/kb/272620 I obtained the updated file from the win-98 service-pack thing (unpacked it manually) and replaced my existing sysdm.cpl. While it did correct the display of a negative free size on the hard drive, it did not solve the virtual memory issue. I then connected another SATA drive to the system (160 gb, with a single 25 gb FAT-32 partition, formatted with 4 kb clusters, a little over 6 million clusters) and Win-98 DID enable virtual memory when instructed to put the swap file on the new drive. So for some reason win-98 did not want to locate the swap file on the 500 gb drive. Either it did not like the fact that the drive was formatted with 4kb cluster size (resulting in 121 million clusters) or it didn't like where on the drive it would have to put it (at the back 10% of the drive). Also - I increased the amount of installed memory to 1 gb, and still got "insufficient memory" when running Windows Scandisk and Defrag on the 500 gb drive. DOS scandisk does not give an error, but it would have taken 4 days to run (given it was at the 30% point after 30 hours). -------------- July 28, 2007 Ron Martell wrote: The FAT32 implementation provides for 28 bits to be used for cluster numbers, which means that it is possible to have up to 268,435,445 total clusters on a drive. Smaller limitations are the result of the tools (FDISK & Format for example) normally used to create FAT32 drives. There is little to no information regarding Win-98's compatibility or operational stability with volumes with large cluster-counts, and just what gets broken at what cluster-count. The year-2000 update to fdisk does work for 250 gb drives (I haven't tried it on a 500 gb drive). Format also works on 250 gb drives, but because of it's use of 32kb cluster size there will be 7.6 million clusters on a 250 gb drive. I am not sure if the native win-98 versions of scandskw.exe, dskmaint.dll and defrag.exe will operate on a volume that exceeds 4.17 million clusters but the win-me versions will, at least up to 31 million clusters. The windows ME versions did not function on a volume with 121 million clusters, displaying an "insufficient memory" message (even on a system with 1 gb memory). The MS-DOS version of scandisk.exe does not seem to have a cluster-count limitation and has been seen to run without issue even on a 500 gb drive with 121 million clusters (although it was only allowed to run for 30 hours before being terminated - it was projected that it would have taken 3 more days to complete it's scan). It has been speculated that the number of clusters is limited because win-98 loads the entire FAT table into memory during normal operational use, but given the recent test with a 121-million cluster drive that theory appears to be wrong. The only issue so far with win-98 installed on a 500 gb volume with 121 million clusters is that it will not create or place the swap file on it, hence virtual memory will not be enabled. It will create / place the swap file on a secondary drive, even if that drive is another 500 gb drive (but formatted with 32kb cluster size resulting in 15 million clusters). |
#18
|
|||
|
|||
Memory hold
98 Guy wrote:
The real problem for win-98 scandisk and defrag is win-98's IDE driver - ESDI_506.PDR. It does not allow correct access beyond the 128 gb point on the drive. Microsoft carefully words their explaination to point the blame at scandisk and defrag being 16 bits instead of their own failing for updating ESDI_506.PDR to the full 48 bits (like they had to do for 2K and XP). With regard to win-98 scandisk and defrag, the answer is to simply use the win-me versions of those apps That's nice! So by the use of WinME disktools the 28 bit IDE driver problem is solved? Maybe you should read what you're writing before posting. |
#19
|
|||
|
|||
Memory hold
98 Guy wrote:
The real problem for win-98 scandisk and defrag is win-98's IDE driver - ESDI_506.PDR. It does not allow correct access beyond the 128 gb point on the drive. Microsoft carefully words their explaination to point the blame at scandisk and defrag being 16 bits instead of their own failing for updating ESDI_506.PDR to the full 48 bits (like they had to do for 2K and XP). With regard to win-98 scandisk and defrag, the answer is to simply use the win-me versions of those apps That's nice! So by the use of WinME disktools the 28 bit IDE driver problem is solved? Maybe you should read what you're writing before posting. |
#20
|
|||
|
|||
Memory hold
"98 Guy" wrote in message ...
wrote: If you connect a hard drive to a win-98 system, and that drive is larger than 128 gb (or 137 Gb, depending on how you define "giga"), then you will screw up the data on the hard drive if windows attempts to write to the drive beyond the 127 gb point on the drive. . . . This only applies to hard drives that are physically connected to the IDE port on the motherboard. I don't believe this applies to USB drives. Using SATA hard drives is a different story . . . USB behavior here confirms the USB comment above. 250 Gb USB drive (preformatted FAT32, used as a single logical drive) now has 184 Gb in use, 66 Gb vacant. Instead of MS I use tools of Fix-It Utilities (and run DiskScan every week or so, DEFRAG seldom -- only if the DiskScan visual display looks strange.) -- Don Phillipson Carlsbad Springs (Ottawa, Canada) |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Too much memory | Franc Zabkar | General | 2 | July 13th 06 11:01 AM |
Display wont hold anything but 16 bit | [email protected] | Monitors & Displays | 0 | September 9th 04 04:10 PM |
What are the directories that hold cookies? | Warren | General | 5 | September 5th 04 08:34 PM |
first power on hangs, requires long hold then re-power on to work | WSchmidt | General | 2 | August 14th 04 10:11 PM |
Paid $35 And Am Still On Hold after 23 minutes???? | Stuart | General | 7 | June 14th 04 08:43 PM |