Simplest (practical) file system?

From: Bob Shannon <bshannon_at_tiac.net>
Date: Thu Jul 31 00:32:55 2003

Sean 'Captain Napalm' Conner wrote:

>
> I have a few questions then. 1) What is the smallest amount of data that
>can be transferred? The largest amount? Any restrictions on data
>placement? (for instance, on old PCs, you could only use the lower 1M (16M
>for 286 or better) of RAM, the smallest amount was 512 bytes, largest 64k
>(128k for 286 or better) but you could not cross a 64k boundary) How much
>space can you set aside for disk buffering?
>
1. The smallest ammount of data read or written to disk is 1024 words.

This value is used due to the HP 1000's paged memory design on all
CPU's, as well as the virtual memory
scheme on the late model 21MX processors. All disk drivers 'translate'
hardware tracks and sectors into
1024 word 'blocks', so all O/S level disk address calculations are
indentical to VM page address calculations.
(in fact, they are the very same routines)

Data is always word-aligned, although 21MX CPU's do support byte
(limited) addressing.

As for 'placement' issues, HP's can only 'see' the current 1024 word
'page', and page zero, not unlike a 16-bit
PDP-8 with larger pages and extra registers. There are only 32 pages at
a time, but you can have 2 mappings
of physical memory (up to 1024 K words) to logical memory (the 32 pages).

Transfers to and from disk do not need to be block boundry aligned.

The current plan (quickly evolving) is to support two disk buffers, each
of 1024 words. Only two files can
be attached at one time without thrashing, but a rather unique method of
saving the file access pointer for each
file in the directory structure. This was a file can be opened,
accessed, then closed, and re-opened at the point of
last access + 1, or you can open the file at the start and seek to any
point in the tranditional method.

>>I think people had to think their software designs through more
>>carefully when they only has 32K. Now that
>>a machine with 32 meg is frowned upon, file systems have become a very
>>different thing in terms of implementation.
>>
>
> Another question: about how big do you expect the average file to be?
>And what type of files do you expect there to be?
>
Your getting to the real issues here!

First, the average file size, I do not beleive we really know at this
point. Lets look at the file types first, and
then look at the relative file sizes.

The first, and most primative file type the O/S understands is an ABS
binary image. This is a variable length
string of 8-bit bytes in a blocked, raw binary format with checksums and
block addresses. These images describe
an absolute addressed binary image which cannot hold more than 32K
words. So the maximum practical ABS
file size is somewhere around 75 kb.

But ABS images must be processed on the fly, during load time, so DMA is
not an option. The result is that ABS
files are not a practical disk format. But ABS is the format
HPdistributed their early software in (like HP Basic, etc).

ABS is really a paper-tape format, best used with hardware emulators as
ultra-fast boot devices.

Once an ABS image is loaded into memory, it can be saved directly to
disk in a raw binary format for fast DMA
transfers. These ram binary image files are never longer than 32K
words. This is the disk boot format.

So once you boot either an ABS image from a paper tape reader emulator,
or a raw binary file from a disk device
and you have the programming language / operating system running we have
a bare-bones system with free memory.

At this point you can load IPL source code into the comand line
interpreter and 'compile' definitions in the dictionary
to provide new keywords for hardware device drivers, floating point
package, or other optional and customized functions
to taylor the running image for your application. So once the engine is
loaded into memory and running it needs to
read a series of 'library' files. These are ASCII IPL source code files
and are generally a few K bytes at most.

It may be practical to place many named definitions inside one disk
'file', and then call them by name from a common
library file.

Of course we want to support general data files for the programmers use
at well.

>
> -spc (Interesting problem ... )
Received on Thu Jul 31 2003 - 00:32:55 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:36:06 BST