Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
VAXF11X04_061 (VAX V6.1 File System) ECO Summary
Copyright (c) Digital Equipment Corporation 1994, 1997. All rights reserved.
PRODUCT: OpenVMS VAX, Version 6.1
COMPONENTS: File System - F11BXQP (XQP)
ACL
BACKUP
SLS
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXF11X04_061
ECO Kits Superseded by This ECO Kit: VAXF11X01_071 (V6.1 Only)
VAXF11X03_070 (V6.1 Only)
VAXF11X02_062 (V6.1 Only)
VAXF11X01_062 (V6.1 Only)
VAXF11X03_061
VAXF11X02_061
VAXF11X01_061
ECO Kit Approximate Size: 320 Blocks
Kit Applies To: OpenVMS VAX V6.1
System/Cluster Reboot Necessary: Yes
Installation Rating: 1 - To be installed on all systems running
the listed version(s) of OpenVMS.
NOTE: In order to receive the full fixes listed in this kit,
the following remedial kits also need to be installed:
VAXSYS06_070 for V6.1 (or its supersedant kit)
Due to a remedial change in the XQP, systems running
V6.1 may be at a greater risk of encountering a memory
management problem that may lead to system crashes.
When this VAXF11X remedial kit is installed on a system,
the VAXSYS06_070 kit should also be installed to ensure
that this problem does not occur. A description of the
memory management problem can be found in the
VAXSYS06_070 kit.
ECO KIT SUMMARY:
An ECO kit exists for F11BXQP.EXE on OpenVMS VAX V6.1. This kit
addresses the following problems:
Problems Addressed in the VAXF11X04_061 Kit:
o An XQPERR bugcheck occurs when trying to create a file.
o A bad FID bugcheck occurs when trying to mark a file header free in
the index file bitmap.
o There are multiply allocated blocks and file headers on the disk.
o Processes hang in an RWAST state while trying to deaccess a file
during channel deassignment.
o The system hangs during cluster wide cache flushes.
o The contents of a header or bitmap block could be corrupted within
the block buffer cache.
o Failure to take an allocation lock could be ignored.
o If a DEACCESS request failed with a SS$_DEADLOCK error, a process
could be left in an RWAST state indefinitely.
o If a large file is created on a fragmented disk that has quotas
enabled and the user needs to use EXQUOTA privilege to allocate the
necessary disk space, an internal XQP table can become corrupted.
This leads to the following bugcheck:
SECAUDERR, Fatal error attempting to perform a security audit
o Attempting to queue a maximal length (39.39;5) filename to the XQP
for spooling to a symbiont would cause either an infinite CPU loop
or the following bugcheck:
FILCNTNONZ, Open file count nonzero after process rundown
Problems Addressed in the VAXF11X01_071 Kit for OpenVMS VAX V6.1:
o The problem occurs when a file is deleted while still being accessed
by someone. This produces an XQPERR bugcheck when an attempt is
made to access the deleted file.
o The problem may result in an XQPERR bugcheck which claims that: "all
the index buffers are active" during the processing of a directory
file.
o System Hang. Processes are stalled waiting to perform I/O
operations, despite buffer credits being available for use.
Problems Addressed in the VAXF11X03_070 Kit for OpenVMS VAX V6.1:
o A system might crash with a SECAUD bugcheck if "ANAL/DISK/ . . ."
is run on a corrupted disk with auditing turned on.
o An XQP bugcheck occurs when a file is accessed for the first time
with cathedral windows, and the accessing process runs out of BYTLM
quota.
o Window mapping code might incorrectly concatenate extents which run
from one volume to another in a volume set.
o An XQPERR bugcheck may occur in [F11X]DIRSCNuPDATE_INDEX() during an
attempt to insert an index entry into a directory index block with
DIR$W_TOTALCELLS equal to zero.
o Directory FCBs can become stale but invisible to the XQP. The File
IDs can then be reused. If the FCB in question is an extension FCB,
the next time the new file is accessed on that node, the XQP will
bugcheck with the fatal XQPERR 'wrong lockbasis with FCB present'.
o If a file is opened for exclusive access on one node in a cluster
and a 'BACKUP/IGNORE=INTERLOCK' command is issued to backup the file
on that node, after the BACKUP completes the file can be
successfully accessed from the other node(s) of the cluster. The
BACKUP destroys the exclusive access.
o BACKUP and SLS can cause WCBFCBMNG bugchecks when operating on some
files. These files are legal, uncorrupted files so they should not
repeatedly cause a crash whenever BACKUP or SLS tries to back them up.
Problems Addressed in the VAXF11X02_062 Kit for OpenVMS VAX V6.1:
o A system may crash with a BADFID bugcheck when a disk file is
deleted. This occurs when INDEXF.SYS is extended and the extension
is not registered by all cluster nodes.
o Due to an XQP error in the directory handling cleanup code, a file
may appear twice in the same directory block.
o Incorrect timing in blocking AST code may cause a system crash with
a BADDALRQSZ bugcheck.
o It is possible for the sequence numbers which protect the index file
bitmap and storage bitmaps to wrap while another node is holding an
obsolete buffer. If that node then decides to use that buffer,
there is a small window during which the invalid buffer could be
seen as valid, and used to allocate blocks on the disk. This is
reported by the system as multiple allocated blocks after a disk has
been defragmented.
o A UNXSIGNAL crash may occur due to a corrupt Window Control Block (WCB).
o When disk quota is exceeded, an extension File Control Block is not
allocated, causing corruption of File Access Control Lists.
Problems Addressed in the VAXF11X01_062 Kit for OpenVMS VAX V6.1:
o On a large, very fragmented disk with little free space and heavy
usage, an XQP lock ranking violation can occur on a regular basis.
o An XQP lock ranking violation may occur during the use of the DCL
'EDIT/EDT' command under the following circumstances:
* User B does not have an entry in the quota file.
* User A has CONTROL access to user B's files. CONTROL access
grants the accessor all the privileges of the object's actual
owner. User A can have this access by either being a member of
the SYSTEM group or having the necessary entry in an ACL.
* User A edits one of user B's files using EDIT/EDT.
o On a disk with highwater marking enabled, a file is created with
several extents, any of which except the last one exceeds 2 Gigabytes
in size. When a write operation is performed on a block in the last
extent of the file, the user may see blocks of a different file
erased incorrectly.
o An XQPERR bugcheck may occur with a message in the code 'FCBs must
be in ascending order'. With XQP+, there can be an unexpected lock
manager error on a DEQ which is attempting to DEQ an FCB address.
The broken FCB chain in question is invariably for a multi-header
directory which is produced by PATHWORKS V5.0 putting many ACLs on
the directory.
o When issuing a DCL 'SET SECURITY/VOLUME' command from the command
line, it is possible to make the XQP crash.
o Due to the resizing of INDEXF.SYS, the following system crashes may
occur:
* 'BADFID, ACP file number out of range for this volume"
* 'Failed to allocate FID when expected'
Problems Addressed in the VAXF11X03_061 Kit for OpenVMS VAX V6.1:
o The executive selects a random process to deassign/deaccess a
global section file. If the VMS File System (XQP) has not
finished initialization of this random process before it is
called to deassign/deaccess the global section file, the
process may hang in the LEF or RWAST state. The hang in RWAST
will occur if a STOP/ID is performed on the process in LEF.
o Certain uses of the SET FILE/ENTER command can "leak" a File
Control Block (FCB) structure. For example, if the file being
entered has more than one header, an FCB is lost for every header.
The extension FCBs have reference counts of 1 so the transaction
count on the disk will be left high (>1). Consequently, the disk
cannot be dismounted because of "[n] user files open on volume".
o During an IO$_CREATE function, usually RENAME, an XQPERR bugcheck
may occur.
o When attempting to create a file on a volume set and a previous
version of the file exists, an XQPERR bugcheck may occur.
o An access violation (ACCVIO) in the routine EXE$SEARCH_RIGHT
results in an UNXSIGNAL crash.
o After deletion of a large file, the free disk space value reported
by SHOW DEVICE can indicate that disks have more or less free space
than the disks actually have.
o Restore ability to use wildcard values for valid UIC owner and group
value ranges.
Problems Addressed in the VAXF11X02_061 Kit for OpenVMS VAX V6.1:
o As of OpenVMS VAX V6.0, movement of directory files is allowed
as long as no node in the cluster has data from these files
cached.
The cluster-wide check for this condition does not work
properly. This results in cache incoherency and, as a result,
directory file corruption. Common symptoms of this problem are:
+ out-of-order directory listings
+ duplicate directory entries for the same file
+ "lost" files
+ inconsistent directory listings on different nodes
+ files appearing in directory listings which are
not "accessible" from the RMS level (i.e., they
cannot be "typed" out).
o Crashes may occur from unexpected SS$_NOTQUEUED after $ENQ with
LCK$M_NOQUEUE. There are several places in the XQP where the
code will $ENQ for a lock on a resource specifying LCK$M_NOQUEUE,
since it does not expect to have to queue for the lock. Under
certain circumstances (detailed below), it will receive back
a status of SS$_NOTQUEUED, indicating that it did not get the
lock since it would had to have queued for the lock. This causes
a fatal bugcheck and the system crashes.
Problems Addressed in the VAXF11X01_061 Kit for OpenVMS VAX V6.1:
o When the ACL of a file is modified, the revision date is not
updated. Therefore, the file will not be backed up by an
incremental backup and data could be lost.
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in
the OPENVMS database. To view these articles, open the appropriate
product database and perform a query using one of the following search
strings: 'VAXF11X04_061', 'VAXF11X', or 'XQP'.
ECO KIT ORDERING INSTRUCTIONS:
If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool. If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled:
[AES] How To Electronically Request ECO Kits Using Service Tools
INSTALLATION NOTES:
In order for the corrections in this kit to take effect, the system must
be rebooted. If the system is a member of a VMScluster, the entire
cluster should be rebooted.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| F11BXQP.EXE |%X6F6CF7BC| XQP V6.1R-0012 | 5-SEP-1997 |
| | | 01:47:40.13 |
+----------------------------+----------+-----------------+--------------+
|
