Some senseless babbling from Jack Stein to Murray Lesser
on 10-25-99  08:23 about File Systems...

 JS> Murray Lesser wrote in a message to Andy Roberts:
 
 AR>While I can think of a lot of reasons to use HPFS rather than FAT, I
 >can not think of any good reason to use FAT rather than HPFS.
 
 ML>     If your whole partition will contain only a few long
 ML> sequential files, FAT is not only faster but has more
 ML> capacity.  I back up to Iomega Zip diskettes using the OS/2
 ML> BACKUP and RESTORE utilities.  It would make no sense
 ML> whatsoever to format those diskettes HPFS. 

 JS> That may be the only instance that FAT might be better, only because
 JS> of space considerations.
 
 ML>     Choice of file system should depend on what one is going
 ML> to put into the partition, not on the "Team OS/2"
 ML> conventional wisdom.  I agree that for general use with
 ML> partitions that are much larger than 100 MB, HPFS has enough
 ML> advantages over FAT to be the preferred choice.  

 JS> I think it has advantages in smaller partitions than 100meg, and
 JS> unless the partition only has (as in your case) one, or a few large
 JS> files, about the  only disadvantage HPFS has is the intital space HPFS
 JS> uses.  If I recall correctly, HPFS generally takes about 7 megs of
 JS> space for whatever it is doing, I don't know what FAT uses, but to me,
 JS> that would be the only issue.   

The largest HPFS structure is the directory band, which varies in size with
the size of the drive.  The minimum size is 102,000 bytes, and the maximum
is 8,192,000 bytes, which is reached at a drive size around 800MB.  In
between, the size of the directory band is, on average, the drive size
divided by 102.64 (out of 27 sample drives between 50MB and 770MB, which
have a minimun ratio of 102.40, and a max of 103.42).

The rest of HPFS's usage is comprised of the following:

1)  LSN's 0 through 20, for BootBlock, SuperBlock, SpareBloc, and other
    stuff.

2)  Four sectors for hotfix entries list.

3)  100 hotfix sectors.

4)  At least four sectors for freespace bitmap list.  An additional four
    sectors for every additional 512 bitmaps required on the drive (each
    four sectors will list bitmaps for an additional 4GB of space, on
    typical drives).

5)  2KB freespace bitmap for every 16384 sectors on the drive.

I've recently also found that there's a bug somewhere in OS/2 that prevents
the use of 4096 free sectors on an HPFS drive, at the end of the drive
(immediately before the last freespace bitmap).  The freespace bitmap shows
the sectors as free, and they don't contain any data, but they are
unreachable (except using direct drive access).

So, for a 100MB ZIP disk, HPFS would be using about the following:

1,021,605 bytes for the directory band
   26,624 bytes for freespace bitmaps
   51,200 bytes for hotfix sectors
   10,240 bytes for structures at beginning
    4,096 bytes for bitmap and hotfix lists
----------
1,113,765 bytes total

I don't know whether or not a ZIP disk would have the same 4096-sector loss
at the end.  If so, that's an additional 2MB off the total.

Mike Ruskai
thannymeister@yahoo.com


... Hey Billy, are you sure they wrote Windoze in Basic?

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
500/3