27 Jul
2003
27 Jul
'03
9:12 a.m.
On Sun, 27 Jul 2003, Bob Shannon wrote:
One such way:
Have some portion of the disk set aside for a fixed
number of directory
entries (the "directory").
This is what RT-11 does, a fixed number of blocks (512 bytes each) are
set aside as the directory. They are read/written in two-block units,
called directory segments, and each segment can handle up to 72 directory
entries.
Each directory entry has a certain number of characters
for a filename
(12 is good), a file type byte, a status byte, and a pointer to the
portion of the disk where the file is stored.
It might also contain the date and time the file was created, or accessed,
or updated. RT only contains the creation date. There was some thought
at one point of getting it to record creation time as well, but was never
done by DEC. Also, RT is a single-user system with the capability of
having multiple jobs running, so for tentative files (ones which haven't
closed yet), there is information kept in the entry about the channel on
which the file is open.
The file data is then stored on consecutive sectors,
with the last one or
two words (depending on word size implemented) pointing to the next
sector of the file. Zero values means "end of file".
Or, as RT did, you have the size of the file in the directory entry, so a
file exists in the contiguous blocks 'start' to 'start+size-1'.
RT also keeps track of the end of a segment so that the directory segments
can be linked in any order as files are created and deleted.
Of course, a more simple method would be to treat the entire directory as
a contiguous set of entries and then you only need an indication of the
end of the directory.
The status info can also keep track of read-only vs. read-write files,
protected files, files which should not be moved in a 'SQUEEZE' operation,
etc.
There also needs to be a map somewhere specifying which
sectors are free/used.
That can be a lot of overhead, and can take up a fair amount of disk space
depending on how it is implemented, and with each directory entry having
start and size, it isn't needed.
With the contiguous file system on RT, one *can* extend a file, though it
either takes intimate knowledge of the directory structure on the part of
the program, or extra code to open a new copy of the file (larger), copy
everything from the old version to the new, closing the old, updating the
new one and closing the new. A program with intimate knowledge of the
directory would have to find the entry for the file, check the next entry
and if it is an empty space, it could increase the file size (up to the
size of the empty) so long as it decreased the size of the empty by the
same amount. Of course if the next entry is not empty, then you have to
revert to the first method.
A program on RT can ask to create a file: 1) a specific size, or 2) half
the largest free space on the disk or the second largest free space
(whichever is greater).
RT attempted to fulfill requests for specific sizes using a best-fit
algorithm which attempted to maximize disk usage by minimizing the size of
free space between allocated files.
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | email: mbg at world.std.com |
| Member of Technical Staff | megan at savaje.com |
| SavaJe Technologies, Inc. | (s/ at /@/) |
| 100 Apollo Drive | URL: http://world.std.com/~mbg/ |
| Chelmsford, MA 01460 | "pdp-11 programmer - some assembler |
| (978) 256 6521 (DEC '77-'98) | required." - mbg KB1FCA |
+--------------------------------+-------------------------------------+