| A question was posted in another conference about the differnces
between Files-11 and Worms-11 and I answered it there. I am placing
it here for reference because this not gets found if you do a
DIR/TITLE=WORMS.
Rob
Worms-11 is a subset of Files-11 with a much simpler on-disk
structure. The VMS docs have descriptions of Files-11 so I
will just contrast parts of Worms-11 to Files-11.
Worms-11 has no BITMAP.SYS. Due to the write-once nature of
the media, the use of an on-disk copy of the bitmap would only
waste space on the disk.
The basic format of the disk is two partitions. The first partition
contains the INDEXF.SYS file and the second contains all the file
data. The blocks are used from low addresses to high. Once either
partition becomes full the disk is full. For this reason, users
of worm media for WORMS-11 volumes must closely estimate the number
of files and file modifications that they expect to make if they
want a high utilization of the media.
The INDEXF.SYS file is pre-allocated at volume initialization time
making it a fixed size. The size is determined by the /MAXIMUM_FILES
qualifier to INIT. Generally speaking it is a little over 2 times
as many blocks as the value of the qualifier. The key point to
remember in estimating this value is not only the number of files
to place on the worm disk, but the number of times you expect to
modify an existing file on the worm disk, more on this later.
The INDEXF.SYS file contains a data structure not found on Files-11
disks that the worm file system uses to help speed up mount operations.
A slightly modified home block exists in the INDEXF.SYS file.
A Worms-11 specific Storage Control Block (SCB) exists in the
INDEXF.SYS file.
The primary data structure found in the WORMS-11 INDEXF.SYS file is
file headers. These file headers have the same format as the Files-11
file headers but the worm file system uses some of the fields in
the file header slightly different. The file headers have pointers to
the blocks in the data area that map the file data.
Another main difference here is that a modification to an existing file
(one not currently accessed or cached) will cause the associated file
header to be modified and rewritten to another location. This consumes
more INDEXF.SYS file space. Files-11 is able to rewrite the modified
file header to the same location in the INDEXF.SYS file. On a WORMS-11
disk each modification of this type consumes more disk space causing
the disk to eventually fill-up. To by products of this exist; first
you cannot locate the most current file header by using the file id as
an index into INDEXF.SYS as you can with Files-11 but you gain an audit
trail of all the modifications of the file. Worms-11 disk have a
generation history of each file maintained in the INDEXF.SYS.
The data area starts just after the last block reserved for the
INDEXF.SYS file or INDEX area. Blocks are written first come first
serve. About 3 years ago, a feature was added to allow for
preallocation of file space but this is done by using a "sparse"
mapping pointers to show the allocated space.
Another primary difference between Worms-11 and Files-11 is in bad block
handling. The worm file system doesn't know if a block will be writable
until a write attempt is made, when the write fails that means any
pointers relating to this block must be changed because the location of
this block must change (an attempt will be made to rewrite it to another
"hopefully good" location). Since these error recovery actions consume
worm blocks it is possible that various hardware error could make all
disk block look bad or the disk may have been nearly full and the error
retries cause writes to be attempted to all the remaining blocks. The
worm file system has a differnt set of problems to handle in these cases
that the Files-11 file system does not have to handle.
Another worm file system implementation change from Files-11 is that
directories are not contiguous. Various test implementations have
show that to enforce a contiguous directory will waste large amount
of worm disk space in some applications. The coding of the directory
support routines is also much simpler than the Files-11 XQP. Also,
the size that many customers let there directories grow to is larger
than the 128 block limit allowed by RMS caching. Between the simple
Worms-11 directory code and the lack of RMS caching, the performance
of directory lookups is poor, in some cases.
The worm file system is also still implemented as an ACP instead of
the XQP implementation of Files-11 file system.
The Worms-11 on-disk structure and implementation are designed to allow
incremental population of the disk in such a way that whenever the
worm disk is out of the drive� it's file structure is complete. This
means that no associated cached data is stored on some other device.
This benifits some customers who must ship media between sites before
it becomes the media becomes full. Some other (competing) implementation
use a caching technique that requires a cached data storage area be
maintained elsewere until the disk is full. This technique has some
advantages but it also has some disadvantages.
Worms-11 does not support volume sets. This is more of an
implementation issue due to the problems associated with the fact
that the media is removable than with the WORMS-11 on-disk structure.
OpenVMS, I beleive, does not support removable media volume sets.
Notes:
� all existing and supported implementations of worm disk drives
with WORMS-11 have used removable media.
|