That would seem to indicate that under FAT32 there could be more sectors
per cluster than in FAT16.
It would further seem to indicate that under FAT32 there would be far
more slack on a HDD than with FAT16 -- because if "addresses" can only
be kept track of for areas of 4K or larger, a small file would leave
behind even more unusable HDD space than under FAT16.
Now, if MicroSoft planned this out, I can believe that they would
squander resources that way -- "It's a company kinda thing." To
paraphrase Intel, "We give you the ability & Windows takes it away."
However, since RAM stores byte-by-byte, it shouldn't require any more
RAM to read a FAT32 than a FAT16 if both had the same number of files.
Point of interest is that with addressable space being so large, there
should be fewer fragmented files under FAT32 which means fewer entries
per file in FAT32 ... hence it could be that FAT32 would require *less*
RAM each reading rather than more [discounting the insignificant number
of bytes difference between 8+3 and LFN].
hmmmmmm ... Microsoft couldn't have intended something like *that* to
happen; it would have to be an accidental side effect of pixxpoor
planning. };>
l.d.
====
On Mon, 04 Dec 2000 10:12:38 +0100 (CET), [EMAIL PROTECTED] (Richard Menedetter) wrote:
> LB> But I think somehow the terminology has gotten twisted.
> I just looked on the web ... and found that:
> http://www.zdnet.com/pcmag/pctech/content/16/07/os1607.010.html
> pcmagazine has put up a table which compares disk size versus _cluster_
> size on fat32
> disks clusters
> -8GB 4K
> -16GB 8k
> -32GB 16K
> 32GB- 32K
--
Join B'FOR - B'mothers For Open Records
<a href=" http://www.b-for.org "> B'FOR web site</A>
[Associate members of triad also welcome; membership confidential.]
Every member counts! We need numbers to produce valid statistics.
*******
A proud member of
<A HREF="http://www.phenomenalwomen.com/"> Phenomenal Women Of The Web</a>
-- Arachne V1.68, NON-COMMERCIAL copy, http://arachne.cz/
