<<< SUBSYS::SYS$ETC:[NOTES$LIBRARY]OPTICAL.NOTE;1 >>> -< Optical Products >- ================================================================================ Note 79.2 WORMS-11 question 2 of 2 TAPE::SENEKER "Head banging causes brain mush" 109 lines 12-FEB-1997 14:49 -< contrast Worms-11 & Files-11 >- -------------------------------------------------------------------------------- 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.