Newsgroups: comp.sys.apple2 Subject: Re: Disassembling an FST... From: dempson@actrix.gen.nz (David Empson) Date: Wed, 16 Sep 1998 02:52:24 +1200 Message-ID: <1dffe91.18ffnvz5ah41qN@dempson.actrix.gen.nz> References: <1dfda69.pf7kjo1w34ohsN@dempson.actrix.gen.nz> <1998091503380100.XAA04188@ladder03.news.aol.com> Organization: Empsoft X-Newsreader: MacSOUP 2.3 NNTP-Posting-Host: 202.49.157.176 X-Trace: 16 Sep 1998 02:50:16 -1200, 202.49.157.176 Lines: 116 Path: news1.icaen!news.uiowa.edu!NewsNG.Chicago.Qual.Net!nyd.news.ans.net!newsfeeds.ans.net!news.idt.net!newsfeed.internetmci.com!203.97.37.7!newsfeed.clear.net.nz!news.iprolink.co.nz!news.actrix.gen.nz!dempson Xref: news1.icaen comp.sys.apple2:139432 cDavid Wilson 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