A few questions here regarding the use of large hard drives with win-98:

I used Seagate Diskwizard on a 160 gb Barracuda drive (SATA) and told it to use 4kb cluster size. Ended up with about 40m clusters (allocation units). Diskwizard went on to put the DOS system files on the drive from a win-98(se) setup floppy. The drive boots find, and chkdsk reports the full disk size. Win-98 is NOT yet installed on it.

The motherboard is Gigabyte 8KNXP (bios updated to Sept/2005 version). CPU is P-4, 3.0 Ghz, 800 mhz FSB. 512 mb system ram (2 banks of 256 mb running in "dual channel" mode).

After power-up, the first time I perform a DIR, it takes 6 minutes for it to report the free disk space.

I understand that a DIR command is computationally intensive for FAT-32 because the entire FAT must be linearly processed to compute free disk space.

After the first DIR command is performed, all other DIR commands are quick (no 6-minute delay) - why is that?

I assume that the Diskwizard software did not perform a full format (physical format?) of the drive - is that a factor with the long time to perform the first DIR command? Or will I always experience this?

Besides scandisk or defrag, is there anything else that is incompatible with having a FAT with 40m allocation units?

I know that there is a patched version of ESDI_506.PDR, but the drive is SATA, being used in SATA mode (not mapped as IDE) so I assume that win-98 (when installed) will not use ESDI_506.PDR so therefore I should be able to have use of the full drive without fear of corruption?

If so, then will Win-98 have a problem with the 4kb cluster size that I've chosen? Are there performance or compatability problems with that and the corresponding large FAT size?

Basically, my question boils down to this: Has anyone else formatted a large drive (either less than or greater than 137 gb) with a "non-standard" cluster size, and found problems with Win-98, and was it more efficient or optimal - or less?

A side question regarding SATA: I currently have 1 drive connected to 4 possible SATA controller channels. Two channels come from the on-board Intel controller, and the other two come from a Silicon Image controller. If I have a second drive connected to the same controller, then am I forced to use both as a RAID? Because if I don't want them to be used as part of a RAID, then I think that they both become mapped as IDE - am I right about that?

A 512 byte cluster size (1 sector) is supposedly usable on FAT32 for disks up to 2 terabytes, but for some reason XP doesn't like it.

The delay after DIR is normal. It's probably the computation of the free space, as you've noted, or something similar.

a customer that formats NTFS can never go back to 9x ($$).

Come on people...

These responses are lame.

Does nobody have any experience with running FAT-32 on large drives with small cluster size?

For those of you using the modified ESDI_506.PDR on drives larger than 137 gb, what are you doing? Are you using 64kb cluster size? That's a waste - and even if you are, you're going to be breaking the 4.7m traditional limit for the number of clusters (allocation units) for FAT-32.

(Or are you dividing up the drive into multiple partitions?)

Is there no knowledge out there as to how well Win-98se handles a FAT that is 2x, 4x, even 16x larger than normal?

I had once set up Windows 98 using 0.5k clustersize on a 500MB partition. This lead to very slow performance while using defrag and scandisk. I now use at least 4KB for the system partition and 32KB clustersize for data partitions for optimal performance.

I have not experimented with small custer sizes because they slow down the drives/partitions considerably.
It's a trade-off:
more space + slow access speed opposite to less space + faster access speed.

FYI:
Undocumented FDISK switches:
http://www.mdgx.com/secrets.htm#FDISK
These PROs + CONs for FAT16 opposite FAT32:
http://www.mdgx.com/secrets.htm#FAT32
are similar to FAT32 large opposite small clusters.

HTH

And as a corollary a quick FAT16 vs FAT32 vs NTFS table:
http://www.ntfs.com/ntfs_vs_fat.htm

I have read somewhere that on both Win9x and NT/2k/XP cluster size should be 4 kb (as in NTFS) because it matches the size of a "page" on I386 architecture.

Bigger sizes appear to slow performance less than smaller ones.

It seems like the new "standard sector" size will be 4,096 bytes instead of 512:
http://www.geekzone.co.nz/content.asp?contentid=6076

Doc:
http://www.idema.org/_smartsite/modules/lo...ta_file_id=1259

jaclaz

32Kb here, actually.

I mostly store large (up to 4GBs) files, so it's not much waste for me.

...that's strange, since all OSs since DOS 3.2 (?) supported sector sizes other than 512 bytes ("Bytes Per Sector" field in superblock), and back in the days of MFM/RLL ST506/512 drives, sector sizes were anywhere from 512 to 8192 bytes.

How do you know if it "slows down the drives/partitions" - you say you haven't experimented with it. ?

That table shows the "max clusters" for FAT-32 to be 4177918. We know that there is nothing intrinsic to Win-98 that corresponds to that limitation other than Fdisk will not (?) create a partition that exceeds that number.

NTFS is listed as being "low performance" on small volumes, but high on large. What exactly is a small and large volume, and why wouldn't the "high" performance on large volumes scale down to small volumes and be "high" on them as well?

Why is Fault-Tolerance for Fat-12 and Fat-16 "average" but for Fat-32 it's "minimal" ?

I have my doubts about the comparison of recoverability. I've recovered files on a fat-32 drive even when the FATs are screwed by using Lost and Found (chain reconstruction).

Indeed, recovering files from an NTFS drive is a bit more difficult due to the more complex structure of the file system.

I use win2000.
A large FAT32 drive with a 512bytes cluster is very slow...
Once a time I converted a NTFS drive (about 44GB) to a FAT32 using Partition Magic 8.0 ...Oh! the cluster remains 512bytes!
Then I use chkdsk to check for errors...no errors...but windows automatically expand my virtual memory size...
Accessing the drive is really very slow.
NTFS has advantages

NTFS has no advantages. I talk to developers who use win-2k and their drives become very fragmented over time - which shoots down the argument that NTFS performs better real-time frag management.

Win-98 really doesn't suffer (performance-wise) on a fast machine when fat-32 becomes fragmented. Win2k, on the other hand, on the same hardware, really bogs.

You have handicapped the FAT-32 drive in your situation by making the cluster size very small (idiotically small) - 512 bytes. Even 2K or XP would not use such a small cluster size when it creates a FAT-32 volume.

Go back and make the cluster size 4kb on that FAT-32 volume and then come back and tell us how slow it is. Not even NTFS uses such a small cluster size (like 512 bytes) on Fat-32 drives.

Geeze.

PS - can someone answer this:

It is said that win-98/Fdisk/Format has a limit of something like 4.17 million clusters (or was it 2 million?)

Why is it that when I try to format an 8-gb volume, that format uses 8 kb cluster size, which results in about 1 million clusters? Why doesn't it use 4 kb cluster size in that case, which would result in 2 million clusters, which is either at the limit, or is half the limit, of this often-quoted 4 million upper limit?

Also:

I recently created a 32 gb FAT-32 partition using 4 kb cluster size - resulting in something like 8 million clusters. I installed win-98 on that partition, and it works fine. I created a secondary partion on the remaining space on that drive (121 gb) also using 4 kb cluster size (resulting in about 30 million clusters).

Norton Ghost 2003 (run from floppy boot) was able to copy (clone) the 32 gb primary partition to another drive, but it was not able to copy the second parition. The source and destination drives were both 160 gb SATA's. This was the error given by Ghost:

------------------------------
Error Number: (29004)
Message: Read sector failure, result = 1, drive = 0, sectors -2084487200 to -2084487199

Version: 2003.789 (May 28 2003, Build=789)
------------------------------

Note the reference to a negative sector number. Would that indicate that ghost is using an improper (or inadequate) variable type to handle the sector number?

Also - when ghost copied the first partition, it did not maintain 4 kb cluster size on the destination drive. It used 16 kb cluster size on the target drive.

NTFS doesn't do automatic defragmentation. File systems for Linux, like EXT3, do.

The wikipedia page is interesting :

File Allocation Table on Wikipedia

Another interesting page :

Fat 32 Formatter