Re: Disassembling an FST...

[Marlin Allred <ma@is6.slc.unisys.com>]

But how well would existing applications work with this enhanced FST?

Marlin

On Wed, 16 Sep 1998, David Empson wrote:

> cDavid Wilson <david@uow.edu.au> wrote:
> 
> > supertimer@aol.com (Supertimer) writes:
> > >Breaking the 32MB limit for the ProDOS FST would be
> > >cool and would it not be possible?  MS-DOS had such
> > >a limit (under the FAT file system) and they broke it after
> > >DOS 4, I think.
> > 
> > Well, it would no longer be ProDOS but let us continue:
> > 
> > 1)    Directory structure would have to change (it is full of block pointers)
> >       so any P8 program that read directories would need to be recompiled or
> >       rewritten.
> 
> Who says ProDOS-8 needs to support this hypothetical new file system?
> Doing so would be next to impossible unless it was specific to the IIgs,
> and made use of native code to implement the file system (via hacks
> through the global page, for example).
> 
> There is no way in hell that another file system could be supported
> within the constraints of the space traditionally available to the P8
> kernel, which effectively rules out 8-bit Apple II support.
> 
> I thought the main goal would be a "ProDOS enhanced" FST for GS/OS.
> This would be a better fit for GS/OS's virtual file system (HFS requires
> some workarounds to be used on the IIgs, and isn't particularly
> efficient due to problems like reversed byte ordering).
> 
> > 2)    The following P8 system calls would have to be replaced by large
> >       disk aware ones:
> > 
> >       READ_BLOCK, WRITE_BLOCK
> > 
> > 3)    Provided we keep the 16MB filesize limits, I think the rest of the
> >       calls would still work.
> > 
> > I guess that Appleshare for ProDOS would give some ideas on how this works.
> 
> It avoids ProDOS completely.  All file system calls associated with the
> network volume are routed elsewhere and handled by the AppleTalk
> protocol stack (PFI, AFP client, and the file server itself).  The only
> link to ProDOS-8 is borrowing spare unit numbers for mapping of network
> drives, and the entry point in the MLI global page.
> 
> > If you do not want to keep compatibilty for ProDOS 8 applications, then you
> > could replace the ProDOS filesystem with anything you wanted.
> 
> A reasonably simple modification, given source to the existing FST :-),
> would be to use a larger logical block size, but retain most of the
> other details of the file system, e.g. 65535 allocation blocks per
> volume.  At the same time, some tweaks could be made to the directory
> structure, e.g. to allow longer file names, a larger maximum file size,
> and to avoid the need for an extra "extended key block" to store files
> with resource forks.
> 
> I'll call this "ProFat" for want of a better name.
> 
> The main disadvantage is an increase in internal fragmentation, but this
> doesn't get to be a serious problem unless you get really big volumes
> (gigabytes per partition).
> 
> Here is a table giving the relevant limits for possible allocation block
> sizes.  I'm assuming only power-of-two block sizes would be supported
> (like MS-DOS), since it makes the code much easier to implement (no
> division required).
> 
> If an arbitrary number of physical blocks can be used in each allocation
> block, it is possible to get maximum efficiency for volume sizes that
> are not close to the values given here, but this is bound to have a
> speed penalty for the extra calculations required.
> 
> Block  Volume    Root Dir     Subdir Files   Bitmap   Sapling  Tree
> Size    Size   Blocks  Files   per Block     Blocks     File   File
> 
>  1KB    64MB      4     51         13           8      512KB     *
>  2KB   128MB      3     77         26           4        2MB     *
>  4KB   256MB      2    103         52           2        8MB     *
>  8KB   512MB      1    103        104           1       32MB     *
> 16KB     1GB      1    207        208           1      128MB     *
> 32KB     2GB      1    415        416           1      512MB     *
> 64KB     4GB      1    831        832           1        2GB     *
> 
> * Tree files are limited by the volume size.
> 
> Methinks that 2GB per volume would be a reasonable upper limit, since it
> would be tricky managing 64K at a time for block accesses.
> 
> Note that SmartPort firmware or a native GS/OS driver is required.  It
> might be possible to boot from a ProDOS-only device, but the files on
> the volume would have to be organised so that the boot driver, FST and
> startup operating system files were located within the first 32MB.
> 
> The nice feature of this implementation is that the file system still
> only needs to deal with 16-bit values for all the pointers maintained by
> the file system (e.g. key block pointer, index block entries).
> 
> Some other details that could be tweaked:
> 
> - Only one block for the boot code (at least 1KB in size, though the
> firwmare will only load the first 512 bytes; if more than 512 bytes is
> required, the first block must load extra blocks as needed).
> 
> - Minimum allocation block size is 1KB.  If 512 byte blocks were
> supported, the file system would be less efficient than ProDOS, due to
> larger directory entries.
> 
> - Index blocks could have the high and low order bytes of their pointers
> adjacent rather than split between the first and second half of the
> block.  This makes it easier for a 16-bit processor to deal with, and is
> more efficient for larger volume sizes, as only part of the index block
> may need to be read.
> 
> -- 
> David Empson
> dempson@actrix.gen.nz
> Snail mail: P.O. Box 27-103, Wellington, New Zealand
> 
>