On Jun 18, 4:53=A0pm, CBFalconer <cbfalco...@yahoo.com> wrote:
> "robertwess...@yahoo.com" wrote:
> > Vladimir Vassilevsky <antispam_bo...@hotmail.com> wrote:
> >> robertwess...@yahoo.com wrote:
>
> >>> My mistake - I was editing and got a FAT16 comment mixed in
> >>> with the FAT32 comment. =A0FAT32 volumes cannot be smaller than
> >>> 32MB, and FAT16 volumes must be smaller than 2GB. =A0FAT32
> >>> volumes can be up to 2TB.
>
> >> Why 2 TB ? 28 bit FAT x 32k cluster =3D 8 TB.
>
> > There's a 32 bit sector count field in the BPB (at +32). =A0If
> > that got patched, I don't know of anything that would prevent an
> > 8TB volume.
>
> The systems using the file system have to keep track of file size.
> They can't measure things larger than 2GB in an int (which they
> need, in order to handle negative offsets in the software).
> Allowing files to grow above 2GB would lead to nasty undetectable
> errors when the file grew past 2GB.


Current FAT32 implementations handle 4GB files just fine (FAT16 can't
support a volume big enough for that size file unless you use large
sectors, FAT12 can't support that big a volume period).  I could
certainly believe that some older ones squawked, or that you might
find an unusual one with an issue.  Applications are also vulnerable
to bugs at that point (and I'm certain we could find plenty that had
problems at that point), but that's a bit of a different issue.

I remember when file sizes first started bumping past 2GB on
mainframes - we definitely ran into problem both in the file systems
(especially VSAM), and in applications (although since these tended to
all be structured files, it was more often the file system with
issues, since the application typically didn't use that offset
directly).

NTFS (along with many other file systems) support files far in excess
of 4GB.  All the native Win32 file APIs use 64 bit values for offsets
(even on FAT =96 you just can=92t create a file big enough to use the high
word there), although in some cases there have been a couple
iterations of those - the original using a pair of 32 bit values, and
a more recent one using a 64 bit value).  Again, I'm sure there are
applications with issues at both 2GB and 4GB.

The 4GB file size limitation on FAT is a problem for many
applications, like media ones, which can produce quite large files,
and some actually go to the trouble of segmenting files so that your
video source ends up as multiple 4GB files on your 100+GB volume.  Or
just insist on NTFS...

And we are talking volume sizes, not file sizes.

On Jun 18, 4:55=A0pm, larwe <zwsdot...@gmail.com> wrote:
> On Jun 18, 12:57=A0pm, "robertwess...@yahoo.com"
>
> <robertwess...@yahoo.com> wrote:
> > There's a 32 bit sector count field in the BPB (at +32). =A0If that got
> > patched, I don't know of anything that would prevent an 8TB volume.
>
> Apparently Windows Me (blerk) can be coerced into using these big
> volumes. Of course, WHY is another question.......


While I won't say it doesn't (and I don't have an Me installation
around to test), it does strike me as odd - first there are a number
of places 32 bit sector numbers float around Win9x, and while some of
the interfaces (for example *some* of the DCB structures) have
provisions for longer sector numbers, I'm not sure how much actually
treats those pairs of ULONGs and 64 bit numbers (rather than just
filling in the low part).  Then there's the issue of where you'd store
the longer sector count in the BPB (presumably at the end, if both the
16 and 32 bit sector count fields are zero), and then there's the
issue of why this would be worth it for only a four fold increase in
storage.

And IIRC, WinMe never supported 48 bit LBA, so any non-SCSI physical
disks would have to have been limited to 128GB.

Further, we're talking about an OS that only shipped between 2001 and
2003, and even extended support has been gone for a couple of years
now.  What would have been to motivation to support volumes that
size?  In 2003, you'd have needed to build an array of 17 120GB*
drives to get to the 2TB limit.  On a machine running Me?!

Could MS have gone to the trouble?  Sure, but why...  And if they had
done it, why not allow Win2K, XP or Vista to mount such a volume?
Heck - it would have made it impossible to upgrade such a machine to
Win2K or XP.  Of course NT never actually supported FAT32 with MS
drivers (there was at least one third party drive that allowed you to
mount a FAT32 volume on NT, and then FAT32 support was added by MS to
Win2K), so there's precedent.

There is certainly some (OK, minimal now, but expected to grow)
pressure from the embedded world to support a larger volume with a
nice simple FS like FAT32, but then it would make sense to allow
cluster numbers above 2**28 too.  You could get to 128TB before
needing major surgery on the format.   And it would still leave you
with a 4GB file size limitation.  Of course MS is pushing (sort-of)
exFAT instead, and the rational for such a format is considerably
reduced if MS isn=92t going to ship support for it in Windows.


*I *think* you could get 120GB drives at the end of '03...

On Jun 18, 12:57=A0pm, "robertwess...@yahoo.com"
<robertwess...@yahoo.com> wrote:

> There's a 32 bit sector count field in the BPB (at +32). =A0If that got
> patched, I don't know of anything that would prevent an 8TB volume.

Apparently Windows Me (blerk) can be coerced into using these big
volumes. Of course, WHY is another question.......

"robertwessel2@yahoo.com" wrote:
> Vladimir Vassilevsky <antispam_bo...@hotmail.com> wrote:
>> robertwess...@yahoo.com wrote:
>>
>>> My mistake - I was editing and got a FAT16 comment mixed in
>>> with the FAT32 comment.  FAT32 volumes cannot be smaller than
>>> 32MB, and FAT16 volumes must be smaller than 2GB.  FAT32
>>> volumes can be up to 2TB.
>>
>> Why 2 TB ? 28 bit FAT x 32k cluster = 8 TB.
> 
> There's a 32 bit sector count field in the BPB (at +32).  If
> that got patched, I don't know of anything that would prevent an
> 8TB volume.

The systems using the file system have to keep track of file size. 
They can't measure things larger than 2GB in an int (which they
need, in order to handle negative offsets in the software). 
Allowing files to grow above 2GB would lead to nasty undetectable
errors when the file grew past 2GB.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

On Jun 17, 8:34=A0pm, "d...@nadler.com" <d...@nadler.com> wrote:
> On Jun 17, 9:20 pm, "robertwess...@yahoo.com"
> > My mistake - I was editing and got a FAT16 comment mixed in with the
> > FAT32 comment. =A0FAT32 volumes cannot be smaller than 32MB, and FAT16
> > volumes must be smaller than 2GB. =A0FAT32 volumes can be up to 2TB.
>
> Um, can't FAT16 go to 2GB ?


Just under.  The maximum number of clusters on a FAT16 volume is 65524
(not 65536).  So the total data area is less than 2GB in all cases.
Looking at the total volume size, the typical size of the reserved
areas (boot stuff, FATs, root directory), will be typically be under
300KB (unless you've got a very large root directory - which you
shouldn't, because many systems won't handle a FAT12/16 root directory
with more than the standard 512 entries, or you have more than two
copies of the FAT =96 again, that=92ll cause compatibility problems), and
that, plus 65524*32K, still doesn't quite get you to 2GB.

Also, it's a pretty bad idea to hit the cluster limit exactly, since
there's a ton of bad code out there with off-by-one or off-by-a-few
errors in their FAT-type* detection code, so it's strongly recommended
that you avoid formatting a volume with cluster counts closer than
about +/-16 to the limits.  Typically you'd go up or down one cluster
size, and end up with twice or half as many clusters, and go from
there.


*It's the number of clusters (and *only* the number of clusters) which
determines the type of volume:  Less than 4085 clusters (IOW 1-4084),
it's FAT12, 4085-65524 it's FAT16, and 65525 or more it's FAT32.  So
the correct way to detect the volume type is to take the sector count,
knock off the reserved, FAT and directory areas, divide by the number
of sectors per cluster (all those values come from the BPB in the
first sector of the volume), to get the cluster count, and compare it
to those limits.

On Jun 17, 8:50=A0pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> robertwess...@yahoo.com wrote:
> > My mistake - I was editing and got a FAT16 comment mixed in with the
> > FAT32 comment. =A0FAT32 volumes cannot be smaller than 32MB, and FAT16
> > volumes must be smaller than 2GB. =A0FAT32 volumes can be up to 2TB.
>
> Why 2 TB ? 28 bit FAT x 32k cluster =3D 8 TB.
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com


There's a 32 bit sector count field in the BPB (at +32).  If that got
patched, I don't know of anything that would prevent an 8TB volume.

larwe wrote:

> On Jun 17, 9:50 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
> wrote:
> 
>>>volumes must be smaller than 2GB.  FAT32 volumes can be up to 2TB.
>>
>>Why 2 TB ? 28 bit FAT x 32k cluster = 8 TB.
> 
> 
> I agree that the on-disk format spec implies that larger volumes can
> be created, but Microsoft specifies that the limits on FAT32 are "32GB
> for all OS, 2TB for some OS".

Probably because 2TB = 512B sector x 32 bit sector count.

>  Look at KB154997 on
> support.microsoft.com. It is probably not a limitation of FAT32 per
> se, but a set of stacked limitations that would (say) make it
> impossible to boot Win98SE on a disk larger than 2TB.

It seems like FAT32 is the most compatible filesystem despite of all 
imperfections.

BTW, I was surprised to find out how big is a file system overhead 
compared to the raw disk speed.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Jun 17, 9:50 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:

> > volumes must be smaller than 2GB.  FAT32 volumes can be up to 2TB.
>
> Why 2 TB ? 28 bit FAT x 32k cluster = 8 TB.

I agree that the on-disk format spec implies that larger volumes can
be created, but Microsoft specifies that the limits on FAT32 are "32GB
for all OS, 2TB for some OS".  Look at KB154997 on
support.microsoft.com. It is probably not a limitation of FAT32 per
se, but a set of stacked limitations that would (say) make it
impossible to boot Win98SE on a disk larger than 2TB.

robertwessel2@yahoo.com wrote:


> My mistake - I was editing and got a FAT16 comment mixed in with the
> FAT32 comment.  FAT32 volumes cannot be smaller than 32MB, and FAT16
> volumes must be smaller than 2GB.  FAT32 volumes can be up to 2TB.

Why 2 TB ? 28 bit FAT x 32k cluster = 8 TB.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Jun 17, 9:20 pm, "robertwess...@yahoo.com"
<robertwess...@yahoo.com> wrote:
> On Jun 17, 8:41 am, "d...@nadler.com" <d...@nadler.com> wrote:
>
> > On Jun 16, 9:37 pm, "robertwess...@yahoo.com"
> > > Just format a USB thumb drive with the "/FS:FAT32" option from the
> > > command line.  No problem so long as it's over 32MB in size and less
> > > than 2GB.
>
> > > Or do the same for a hard disk partition.  Note that you cannot format
> > > a floppy FAT32, since it's not possible to put enough clusters on a
> > > floppy to get past the 65536 cluster threshold so that it will be
> > > detected as a FAT32 volume.
>
> > Um, sorry if I'm missing something, but why "less than 2GB" ?
> > Isn't FAT32 good for many orders more than 2GB ?
>
> My mistake - I was editing and got a FAT16 comment mixed in with the
> FAT32 comment.  FAT32 volumes cannot be smaller than 32MB, and FAT16
> volumes must be smaller than 2GB.  FAT32 volumes can be up to 2TB.

Um, can't FAT16 go to 2GB ?