Re: Disassembling an FST: Retort

[dempson@actrix.gen.nz (David Empson)]

Brian Hammack <brian.hammack@rook.wa.com> wrote:

>  Antoine raised the cup and toasted:
> 
>  AV<| Please let me tell you a story. The story of the HFS FST (I think
>     | I did it before).
> 
> Nice story!  :)
> 
>     | - the FST is bugged. Thanks for us, some guys patched it.
> 
> I commented to someone in CSA2 the other day that Brutal Deluxe should
> put out the improved System as a package, as opposed to someone's
> suggestion that BD make a program that patches a bunch of stuff, so
> that things like the HFS FST are already patched and reliable.
> 
>  AV<| They lived happily ever after (no child named HFS+)
> 
> Which brings me to my question, which no one in CSA2 has responded to,
> of how feasable or possible an HFS+ FST would be to write.

HFS+ would be major overkill, as mentioned elsewhere.  I don't see any
practical reason for using it, as most of its special features go way
beyond the abstract file system provided by GS/OS, and it would be even
harder for the IIgs to handle HFS+ than it is to handle HFS.

I haven't seen a detailed spec of HFS+, but information gleaned from
various sources points to the following major features.  I've noted
IIgs-specific issues in square brackets after each point.

- Similar underlying organisation to HFS, presumably still using B*
trees for catalog and extent files.

- 32-bit allocation block numbers.  [32-bit data is somewhat inefficient
to process on the 65816, especially as the bytes have to be reversed in
this case.]

- Filenames may contain up to 255 Unicode characters (not supported on
the Mac yet).  [Unicode isn't supported anywhere on the IIgs, so this
feature is of no practical use.  The filename length probably exceeds
what the majority of applications are prepared to deal with.]

- Compared to HFS, HFS+ doesn't get significantly less wasteful until
you get disk sizes in the order of 500 megabytes.  [This is approaching
the upper limit of what I'd consider to be a practical volume size for
the IIgs.]

- Possibly other features intended for MacOS X (UNIX extensions).  [No
support for these features under GS/OS.]

>     | The 16mb may remain (have any interest in a bigger size for a
>     | limit of 8mb of ram?)
> 
> I'd say there's interest.  This is the reason why I have 8mb and not
> higher (I have two 4mb cards in a RamKeeper); I don't like being FORCED
> to use whatever ram I have above that 8mb for a ramdisk or for nothing
> at all.  Is there actually a way to break the usable-8mb barrier?

I think the previous poster was referring to the 16MB limit on file
sizes, and suggesting that you cannot effectively use huge files with a
maximum of 8MB of RAM.

This is not a valid argument for retaining a 16MB file limit, IMHO.
Consider a large database file, which is randomly accessed in small
pieces.  This could quite reasonably be much larger than 16 MB,
especially if the file system supports sparse files (which neither
MS-DOS nor HFS does).

As to the 8 MB RAM limit: that is outside the realm of this discussion,
but I've commented on it before.  We can start another thread if you
like.  :-)
 
>     | The length of filenames may be up to 31 characters long

I'd like them to be even longer, but I'd be happy with a 31 character
limit, simply for convenience (at least one other file system - HFS -
could represent the filename without having to mangle it).

>     | The size of a block may remain at 512b

Why?  Accessing 512 bytes at a time is inefficient, since there is the
overhead of keeping track of all these small blocks, and doing I/O
requests for small and scattered pieces of data.

This is less of an issue if the file system is designed to allocate
blocks in contiguous chunks, as with OS/2 HPFS, and NT's NTFS.  Other
file systems (including ProDOS, HFS and FAT) don't do as good a job,
though HFS tries harder than the other two.

The real question is what sort of file size distribution you have.  If
most files are 8K or smaller, it would obviously be inefficient to use
allocation blocks larger than 8K, since you would be wasting a large
proportion of each block.  A block size of 2K or 4K might be quite
acceptable, and would be much more efficient than 512 bytes.

>     | The number of logical blocks may be larger than 64k

I don't like this idea, because it means the processor is having to do a
lot of processing with numbers larger than 16 bits.  This slows down all
the calculations, since the registers are only 16 bits.

> Fine by me.  How about the number of files in a directory, can this be
> made to exceed 128?  (Maybe I should say "reliably exceed 128"; in my
> experience more than that number, although permissible, is unreliable.)

That depends more on other components of the system software and
application limits, in particular the Standard File toolset and Finder.
GS/OS and the FST almost certainly don't care, though I imagine HFS has
to work a little harder with lots of files per directory.

Other than the root directory, ProDOS has no arbitrary limit on the
number of files per directory, as I'm sure most people know.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand