I was just sitting at the computer thinking about today's 200 GB drives
with the EB drives probably coming out in the not too distant future. Now we
all know FAT32 is too inefficient for such storage space and NTFS is usually
used. But what about ext3 ? Can it handle such HDs? Could a FAT64 be
developed that wouldn't waste so much space? Or will FAT disappear and not
be used again?

My ponderings made open for discussion.

Bill

Bill Cunningham wrote:
> I was just sitting at the computer thinking about today's 200 GB drives
> with the EB drives probably coming out in the not too distant future. Now we
> all know FAT32 is too inefficient for such storage space and NTFS is usually
> used. But what about ext3 ? Can it handle such HDs? Could a FAT64 be
> developed that wouldn't waste so much space? Or will FAT disappear and not
> be used again?
>
> My ponderings made open for discussion.


You're expecting that we skip terabyte and petabyte drives, then?

FAT32 goes tilt at 8TB.  Doing a "FAT64" would be trivial, although
somewhat harder than doing FAT32 was (you'd have to implement a larger
directory entry), although the question would it be worthwhile, and why
you would want such a beast?

And exactly how does FAT32 "was so much space?"

Current versions of ext3 are limited to 32TB, I think, but and
extension to support larger volumes would likely be straight forward,
although they'll likely end up calling ext4.  And if you need a *nix
file system that can handle large volumes now, there's (at least) HFS,
JFS, UFS2, XFS, and ZFS.  Have the people who name these things no
imagination whatsoever?

> You're expecting that we skip terabyte and petabyte drives, then?

    Oh no of course TB. I completely forgot what we're going to call the
next series.

> FAT32 goes tilt at 8TB.  Doing a "FAT64" would be trivial, although
> somewhat harder than doing FAT32 was (you'd have to implement a larger
> directory entry), although the question would it be worthwhile, and why
> you would want such a beast?

    For posterity I guess. More than anything else. Since it was designed
for old floppies and MS has modernized it. Why not continue the tradition
even though MS isn't using it anymore.

>
> And exactly how does FAT32 "was so much space?"

    Cluster size on huge drives. I meant waste. Geesh imagine a cluster of
4096 and a 32 MB file. Alot of wasted cluster space.

> Current versions of ext3 are limited to 32TB, I think, but and
> extension to support larger volumes would likely be straight forward,
> although they'll likely end up calling ext4.  And if you need a *nix
> file system that can handle large volumes now, there's (at least) HFS,
> JFS, UFS2, XFS, and ZFS.  Have the people who name these things no
> imagination whatsoever?
>

robertwessel2@yahoo.com wrote:
> Bill Cunningham wrote:
> > I was just sitting at the computer thinking about today's 200 GB drives
> > with the EB drives probably coming out in the not too distant future. Now we
> > all know FAT32 is too inefficient for such storage space and NTFS is usually
> > used. But what about ext3 ? Can it handle such HDs? Could a FAT64 be
> > developed that wouldn't waste so much space? Or will FAT disappear and not
> > be used again?
> >...
> Current versions of ext3 are limited to 32TB, I think, but and
> extension to support larger volumes would likely be straight forward,
> although they'll likely end up calling ext4.  And if you need a *nix
> file system that can handle large volumes now, there's (at least) HFS,
> JFS, UFS2, XFS, and ZFS.

Not forgetting reiser3fs with a filesystem limit of 17.6TB, according
to http://www.everything2.com/index.pl?node_id=510028
I cannot locate information on the the limits of Reiser4
(http://www.namesys.com/v4/v4.html).

SGI XFS' limit on 2.6 is "9 million TB" according to
http://oss.sgi.com/projects/xfs/

Apple HFS+ can handle filesystems of up to 16 TB according to
http://docs.info.apple.com/article.html?artnum=25557

A table of uncertain accuracy listing many more filesystems is here:
http://www.mrsci.com/Computer-File-Systems/Comparison_of_file_systems.php

> Have the people who name these things no
> imagination whatsoever?

Bill Cunningham wrote:
>  For posterity I guess. More than anything else. Since it was designed
> for old floppies and MS has modernized it. Why not continue the tradition
> even though MS isn't using it anymore.


I spent some time thinking about this yesterday, and there are
certainly some applications where a rather dumb, but very simple FS
might be useful.  I'm thinking of all those cameras, PDA, cell phones,
and whatnot with FAT formatted flash drives in them.  What happens when
the typical SD card hits 2TB?  Perhaps a FAT64 format makes sense
there.

And, on that note, there's actually a 2TB limit on FAT32.  When I said
8TB, I was thinking 28 bit FAT entries times 32KB clusters, completely
forgetting that there's a (*single*) 32 bit sector count in the BPB,
which limits a volume to 2TB.  Of course MS (trivially) patched around
that once before (there was originally a 16 bit sector count - the rule
is that if the 16 bit sector count is zero, you need to read the 32 bit
field).


> >
> > And exactly how does FAT32 "was so much space?"
>
>     Cluster size on huge drives. I meant waste. Geesh imagine a cluster of
> 4096 and a 32 MB file. Alot of wasted cluster space.


A 4KB cluster on a 32MB file does not seem to waste much space to me.
And if you mean the FAT entries themselves, you've only got four (or
eight, if there are two copies of the FAT)  bytes per cluster (.4% for
2KB clusters).  And FAT32 can do a 2TB disk with 8KB clusters.  Where
large clusters bite is when you have many small files.

robertwessel2@yahoo.com wrote:
> ...
> A 4KB cluster on a 32MB file does not seem to waste much space to me.
> ...  Where
> large clusters bite is when you have many small files.

Like, for instance, cached image thumbnails? There would be *a lot* of
those on a 2TB drive full of 32MB JPEGs.

toby wrote:
> robertwessel2@yahoo.com wrote:
> > ...
> > A 4KB cluster on a 32MB file does not seem to waste much space to me.
> > ...  Where
> > large clusters bite is when you have many small files.
>
> Like, for instance, cached image thumbnails? There would be *a lot* of
> those on a 2TB drive full of 32MB JPEGs.


Thumbnails seem to typically be at least several KB in size, and their
number is pretty much limited to the number of full images stored.
But, to use your example, a 2TB drive full of 32MB JPEGs would have no
more than 64K thumbnails, which would waste no more than one cluster
each - or a maximum of 2GB, even with 32KB clusters, or .1% of the
drive (or the equivalent of 64 full sized JPEGs).

<robertwessel2@yahoo.com> wrote in message 
news:1140329366.556123.285260@o13g2000cwo.googlegroups.com...
>
> there's (at least) HFS,
> JFS, UFS2, XFS, and ZFS.  Have the people who name these things no
> imagination whatsoever?

    When an acronym ends with FS and the context is operating system 
components, I can usually infer that we're talking about some sort of file 
system (so I might have had some trouble with UFS2, but maybe not; too late 
to tell now.)

    If you start giving them names like "Avalon", "Yukon", "Bulverde", etc. 
I'd have no idea what you're talking about. Could be a file system, but 
could be a new GUI or DRM subsystem for all I know.

    Imaginative names might be good for marketting, but they're not so good 
for technical discussions.

    - Oliver