OpenVMS VAXF11X03_070 VAX V5.5-2 - V7.0 File System ECO Summary
NOTE: An OpenVMS saveset or PCSI installation file is stored
on the Internet in a self-expanding compressed file.
The name of the compressed file will be kit_name-dcx_vaxexe
for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha.
Once the file is copied to your system, it can be expanded
by typing RUN compressed_file. The resultant file will
be the OpenVMS saveset or PCSI installation file which
can be used to install the ECO.
*OpenVMS] VAXF11X03_070 VAX V5.5-2 - V7.0 File System ECO Summary
Copyright (c) Digital Equipment Corporation 1994, 1996. All rights reserved.
OP/SYS: OpenVMS VAX
COMPONENTS: File System - F11BXQP (XQP)
ACL
BACKUP
SLS
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXF11X03_070
ECO Kits Superseded by This ECO Kit: VAXF11X02_070
VAXF11X01_070
VAXF11X02_062
VAXF11X01_062
VAXF11X03_061
VAXF11X02_061 (CSCPAT_1137)
VAXF11X01_061
VAXF11X03_060 (CSCPAT_1096)
VAXF11X02_060
VAXF11X01_060
VAXF11X04_U2055 (CSCPAT_1162)
VAXF11X03_U2055
VAXF11X02_U2055
VAXF11X01_U2055
ECO Kit Approximate Size: 1348 Blocks
Saveset A - 126 Blocks
Saveset B - 216 Blocks
Saveset C - 216 Blocks
Saveset D - 234 Blocks
Saveset E - 234 Blocks
Saveset F - 270 Blocks
Cover Letter - 52 Blocks
Kit Applies To: OpenVMS VAX V5.5-2, V5.5-2H4, V5.5-2HF,
V6.0, V6.1, V6.2, V7.0
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, V6.2 and V7.0 installations only.
Due to a remedial change in the XQP, systems running the
versions listed above may be at a greater risk of
encountering a memory management problem that may lead
to system crashes. When the VAXF11X03_070 remedial kit
is installed on a system, the VAXSYS06_070 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 remedial kit.
ECO KIT SUMMARY:
An ECO kit exists for F11BXQP.EXE on OpenVMS VAX V5.5-2 through V7.0.
This kit addresses the following problems:
Problems Addressed in the VAXF11X03_070 Kit for OpenVMS VAX V6.1,
V6.2 and V7.0:
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.
Problems Addressed in the VAXF11X03_070 Kit for OpenVMS VAX V5.5-2,
V5.5-2H4, V5.5-2HF, V6.1, V6.2, and V7.0:
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_070 Kit for OpenVMS VAX V7.0:
o The VAXF11X01_070 remedial kit placed the OpenVMS VAX V7.0
F11BXQP.EXE image in the SYS$SYSTEM directory. For V7.0 the
location of this file changed. The file should now be placed in
the SYS$LOADABLE_IMAGES images directory.
Problems Addressed in the VAXF11X01_070 Kit for OpenVMS VAX V7.0:
o When enabling quotas on the system disk, the system occasionally
crashes with an ACCVIO.
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 UNXSIGNAL crash due to a corrupt Window Control Block.
o File Access Control Lists are corrupted after a failure to allocate
an extension File Control Block due to disk quota being exceeded.
Problems Addressed in the VAXF11X01_070 Kit for OpenVMS VAX V5.5-2,
V5.5-2H4, V5.5-2HF:
o This fix merges the PWXQP+ threaded OpenVMS VAX V5.5-2 XQP with the
OpenVMS VAX remedial V5.5-2 code. From this point on, all V5.5-2
XQP kits will provide the threaded version of the XQP. This XQP has
exactly the same functionality as the current V5.5-2 XQP except when
multi-threading is explicitly enabled.
Problems Addressed in the VAXF11X02_062 Kit:
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.
o File Access Control Lists become corrupted after a failure
to allocate an extension File Control Block due to disk quota
being exceeded.
Problems Addressed in the VAXF11X01_062 Kit:
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.
Problems Addressed in the VAXF11X03_061 Kit for OpenVMS VAX V5.5-2 and
V6.1:
o An access violation (ACCVIO) in the routine EXE$SEARCH_RIGHT
results in an UNXSIGNAL crash.
Problems Addressed in the VAXF11X03_061 Kit for OpenVMS VAX V5.5-2, V6.0
and V6.1:
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.
Problems Addressed in the VAXF11X03_061 Kit for OpenVMS VAX V6.0 and
V6.1:
o The ability to use wildcard values for valid UIC owner and group
value ranges has been restored.
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.
Problems Addressed in the VAXF11X03_060 Kit for OpenVMS VAX V6.0:
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).
Problems Addressed in the VAXF11X02_060 Kit for OpenVMS VAX V6.0:
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.
Problems Addressed in the VAXF11X01_060 Kit for OpenVMS VAX V6.0:
o When a file is opened with an NL mode access lock, an attempt
to access an extension header may fail because the FCB chain is
being re-built.
o The BACKUP utility accesses file extension headers directly
without going through the synchronization of the primary
header. This allows the FCBs for the headers being looked
at by BACKUP to be deallocated by other processes. The
results of this are exhibited as any one of several different
XQP bugchecks. The most notable of these bugchecks are
UNXSIGNAL (ACCVIO), NOTFCBFCB and XQPERRs.
Problems Addressed in the VAXF11X04_U2055 Kit for OpenVMS VAX V5.5-2:
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 VAXF11X03_U2055 Kit for OpenVMS VAX V5.5-2:
o If an application tries to access (IO$_ACCESS | IO$M_ACCESS)
an extension header directly when the file (primary header/-
File Control Block) is not open, the call usually fails with
SS$_NOSUCHFILE. However, if the header is the first extension
header in a chain and contains only mapping pointers, an
incorrect SS$_ACCONFLICT error is returned. If the header
contains an ACL, an [F11X]INIFC2.B32/FILL_FCB crash occurs.
The offset of this crash varies.
o When accessing extension headers directly, cached File Control
Blocks from the Virtual I/O Cache (VIOC) can appear to be the
primary File Control Block. This can cause unsynchronized
access to extension headers.
Problems Addressed in the VAXF11X02_U2055 Kit for OpenVMS VAX V5.5-2:
o There is a basic lock manager design problem that manifests
itself in two different file system problems.
1. Occasionally access to a cluster-shared file is
incorrectly denied to an accessor. An application
will attempt to access a shared file in what looks
to be a compatible way and will receive an
SS$_ACCONFLICT status.
2. Occasionally an application will create a new file
and the system will crash in CREATE with an XQP
bugcheck whose text says "how can we fail to
access a new file."
o When a file is open with an NL mode access lock, an attempt
to access an extension header may fail because the FCB chain
is being rebuilt.
o The BACKUP utility accesses file extension headers directly
without going through the synchronization of the primary
header. This allows the FCBs for the headers being looked
at by BACKUP to be deallocated by other processes. The
results of this are exhibited as any one of several different
XQP bugchecks. The most notable of these bugchecks are
UNXSIGNAL (ACCVIO), NOTFCBFCB and XQPERRs.
Problems Addressed in the VAXF11X01_U2055 Kit for OpenVMS VAX V5.5-2:
o Reading beyond the File Highwater Mark (FHM) returns a
success status but the user's buffer is not modified.
This problem manifested itself principally when doing
BACKUP/VERIFY on files whose FHM was less than the
physical file size. When condition occurs under BACKUP,
a %BACKUP-E-VERIFYERR error is returned.
This problem is fixed in OpenVMS VAX V6.0.
o If a write error is encountered while writing directory
data blocks, the system may crash with an XQPERR bugcheck
at REMOVE+4F. Directory corruption may also occur.
This problem is fixed in OpenVMS VAX V6.0.
o The file system will attempt to acquire and subsequently
release a SERIAL lock of a particular file while it still
holds the ALLOCATION lock for the volume on which the
particular file exists. This is incorrect behavior.
This problem is fixed in OpenVMS VAX V6.0.
o Disk space is inefficiently used due to the default extension
size of INDEXF.SYS. The algorithm now tries to extend the
file by 15% of MAX_FILES - HEADERS_USED. It does this until
the index file has grown to 90% of MAX_FILES. From then on
the file is extended in increments of 1% of MAX_FILES.
This problem is fixed in OpenVMS VAX V6.0.
CSC NOTE: This problem may also occur on OpenVMS Alpha V6.1.
The AXPF11X02_061 ECO kit will fix the problem on
OpenVMS Alpha V6.1.
o During a cluster transition, lock value blocks may normally
become invalid. However, the file system does not take
appropriate action when encountering invalid value blocks.
This problem is fixed in OpenVMS VAX V6.0.
o When running DECps and using the hot file collection feature,
the system may crash with a FCBNOTFCB bugcheck if a process
accesses an extension file header by FID (File ID) at the
same time that the header is being deleted.
This problem is fixed in OpenVMS VAX V6.0.
o When two processes access a shared file which has multiple
file headers, one process may fail with an SS$_PAGRDERR error.
For example:
- Image A creates FILE.DAT
- Image A writes 100 blocks to FILE.DAT
- Image B opens FILE.DAT
- Image B calls $CRMPSC and maps FILE.DAT
- Image A extends FILE.DAT to 200 blocks (FILE.DAT now has
multiple file headers)
- Image B calls $CRMPSC and remaps FILE.DAT
- Image B tries to reference address returned from $CRMPSC
and terminates with a SS$_PAGRDERR error.
This problem is fixed in OpenVMS VAX V6.0.
o On a very fragmented disk, if the creation of a new file
causes INDEXF.SYS to be extended, the index file may become
corrupt. When this occurs, the 'DUMP/HEADER INDEXF.SYS' DCL
command displays a value of 256. The ANALYZE/DISK command
returns an "invalid map area" error.
This problem is fixed in OpenVMS VAX V6.0.
o If a nonprivileged user performs a 'SET FILE/NODIRECTORY'
command on a directory file that he does not own, an error
is not returned. However, the file retains the directory
attribute.
This problem is fixed in OpenVMS VAX V6.0
o Possible data corruption occurs after EXTEND failures on
bound volume sets when the Window Control Block (WCB) is
not reinitialized properly.
This problem is fixed in OpenVMS VAX V6.0.
o The system crashes when reading a corrupt directory entry
instead of returning a SS$_BADIRECTORY status.
This problem is fixed in OpenVMS VAX V6.0.
o Problems occur when the file system accesses directories
that are created non-contiguous by a QIO request. This QIO
request is no longer allowed.
This problem is fixed in OpenVMS VAX V6.0.
o Under the following very specific set of conditions, the
contents of a file may be corrupted by the file system:
1. File must be on Bound Volume Set
2. File must NOT be on RVN 1
3. File must be open
4. System must be running standalone, or the Bound Volume Set
must not be available to any other node in a cluster.
This problem is fixed in OpenVMS VAX V6.0.
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 must be rebooted.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
vaxf11x03_070.README
vaxf11x03_070.CHKSUM
vaxf11x03_070.CVRLET_TXT
vaxf11x03_070.a-dcx_vaxexe
vaxf11x03_070.b-dcx_vaxexe
vaxf11x03_070.c-dcx_vaxexe
vaxf11x03_070.d-dcx_vaxexe
vaxf11x03_070.e-dcx_vaxexe
vaxf11x03_070.f-dcx_vaxexe
|
