| I Install this patch on the system and i see the result, but i have the
explain in end of the page 6 of this release notes.
The latest version de DEFRAG is well V2.2 and i install it.
Thanks.
Michel Berenguier
_______________________________________________________________________
Kit Name:
VAXF11X03_070
Kit Description:
Version(s) of OpenVMS to which this kit may be applied:
OpenVMS VAX V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1, V6.2, V7.0
Files patched or replaced for OpenVMS VAX V5.5-2, V5.5-2H4,
V5.5-2HF
o [SYSEXE]F11BXQP.EXE (new image)
Files patched or replaced for OpenVMS VAX V6.0
o [SYSEXE]F11BXQP.EXE (new image)
Files patched or replaced for OpenVMS VAX V6.1
o [SYSEXE]F11BXQP.EXE (new image)
Files patched or replaced for OpenVMS VAX V6.2
o [SYSEXE]F11BXQP.EXE (new image)
Files patched or replaced for OpenVMS VAX V7.0
o [SYS$LDR]F11BXQP.EXE (new image)
Problems addressed in VAXF11X03_070 kit for OpenVMS V6.1, V6.2, V7.0
o A system could crash with a SECAUD bugcheck whenever
ANAL/DISK/etc is run on a corrupted disk with auditing turned
on.
Page 2
o The XQP bugchecks 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 could incorrectly concatenate extents which
ran from one volume to another in a volume set.
o XQPERR bugcheck in [F11X]DIRSCNuPDATE_INDEX() when trying to
insert index entry into 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, and if the FCB in question was an
extension FCB, the next time the new file is accessed on that
node, the XQP bugchecks 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 VAXF11X03_070 kit for OpenVMS VAX V5.5-2,
V5.5-2H4, V5.5-2HF, V6.1, V6.2, 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 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 VAXF11X01_070 kit for OpenVMS VAX V7.0
o When enabling quotas on the system disk, the system
occasionally crashes with an ACCVIO.
o File name appears twice in a directory block.
o System crashes with a BADDALRQSZ bugcheck
Page 3
o Multiple allocated blocks being reported after the defragger
has been run
o UNXSIGNAL crash due to a corrupt Window Control Block
o File Access Control Lists are corrupted after a failure to
allocated an extension File Control Block due to disk quota
being exceeded.
Problems addressed in 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 VAXF11X02_062 kit
o The system crashes with a BADFID bugcheck.
o File name appears twice in a directory block.
o System crashes with a BADDALRQSZ bugcheck
o Multiple allocated blocks being reported after the defragger
has been run
o UNXSIGNAL crash due to a corrupt Window Control Block
o File Access Control Lists are corrupted after a failure to
allocated an extension File Control Block due to disk quota
being exceeded.
Problems addressed in 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 Lock Ranking Violation (with EDIT/EDT usage). The problem is
caused under the following circumstances:
o User B does not have an entry in the quota file.
Page 4
o User A has CONTROL access to user B's files. CONTROL
access grants the accessor all the privileges of the
objects actual owner. User A can have this access by
either:
- being a member of the SYSTEM group
- having the necessary entry in an ACL.
o 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, of which any extent, except the last one,
exceeds 2 Gb 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 The user sees an XQPERR bugcheck, with a message in the code
'FCBs must be in ascending order', although with XQP+ there can
be an unexpected lock manager error on a DEQ (where the
DIRLCKID and PRIMFCB fields of an FCB overlap and we try to DEQ
an FCB address. The broken FCB chain in question is invariably
for a multi-header directory (produced by PATHWORKS V5 putting
lots of ACLs on the directory).
o When issuing a set security/volume command from the command
line, it is possible to make the XQP crash.
o Due to INDEXF.SYS resizing the system may cash with the
following errors:
o BADFID, ACP file number out of range for this volume
o Failed to allocate FID when expected
Problems addressed in 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 Some uses of the set file /enter command can "leak" an FCB
structure. 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 Fix an XQPERR bugcheck which can occur during an IO$_CREATE
function (usually RENAME).
Page 5
Fix an XQPERR bugcheck which occurs when attempting to create a
file on a volume set when a previous version of the file
exists.
Problems addressed in VAXF11X03_061 for OpenVMS VAX V5.5-2, V6.1
o An ACCVIO in routine EXE$SEARCH_RIGHT results in an UNXSIGNAL
crash.
Problems addressed in VAXF11X03_061 kit for OpenVMS VAX V5.5-2, V6.0,
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 they actually have.
Problems addressed in VAXF11X03_061 kit for OpenVMS VAX V6.0, V6.1
o Restore ability to use wildcard values for valid UIC owner and
group value ranges.
Problems addressed in VAXF11X02_061 kit for OpenVMS VAX V6.1
o As of V6.0, the XQP MOVEFILE primitive allows movement of
directory files, so long as no node in the cluster has data
from these files cached.
The cluster-wide check for this condition did not work
properly. This results in cache incoherence, and as a result,
directory file corruption.
Common symptoms are:
o out of order directory listings
o duplicate directory entries for the same file
o "lost" files
o inconsistent directory listings on different nodes
o files appearing in directory listings which are not
"accessible" from the RMS level (e.g. you can't type them)
Page 6
o 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. On very odd
occasions (detailed below) it will receive back a status of
SS$_NOTQUEUED, indicating that it did not get the lock since it
would have had to have queued for the lock. This causes a
fatal bugcheck and the system crashes.
Problems addressed in VAXF11X01_061 kit for OpenVMS VAX V6.1
o Post V6.0, when the ACL on 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 VAXF11X03_060 kit for OpenVMS VAX V6.0
o As of V6.0 the XQP MOVEFILE primitive allows movement of
directory files, so long as no node in the cluster has data
from these files cached. Unfortunately the cluster-wide check
for this condition is broken. This results in cache
incoherency and consequently directory file corruption. Common
symptoms 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 (e.g. you can't type them)
Problems addressed in VAXF11X02_060 kit for OpenVMS VAX V6.0
o Post V6.0 when the ACL on a file is modified the revision date
is not updated, hence it will not be backed up by an
incremental backup hence prospect of lost data.
Problems addressed in VAXF11X01_060 kit for OpenVMS VAX V6.0
o When a file is open with a NL mode access lock then an attempt
to access an extension header may fail because the FCB chain is
being rebuilt.
Page 7
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 VAXF11X04_U2055 kit for OpenVMS VAX V5.5-2
o 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. On very odd
occasions, it will receive back a status of SS$_NOTQUEUED,
indicating that it did not get the lock since it would have had
to have queued for the lock. This causes a fatal bugcheck and
the system crashes.
Problems addressed in VAXF11X03_U2055 kit for OpenVMS VAX V5.5-2
o An application tries to access (IO$_ACCESS | IO$M_ACCESS) an
extension header directly when the file (primary header/FCB) is
not open. The call should fail with SS$_NOSUCHFILE, and does
most of the time. However, if the header is the first
extension header in a chain, if the header contains just
mapping pointers, we return a bogus SS$_ACCONFLICT. If the
header contains an ACL we take a crash in
[F11X]INIFC2.B32/FILL_FCB (offset varies).
Inspection of the code while attempting to locate the cause of
this problem exposed another problem. We can pick up cached
FCBs from VIOC as the primary FCB when accessing extension
headers directly - thus getting a bogus "access" on the
primary, allowing unsynchronized access to extension headers.
Problems addressed in VAXF11X02_U2055 kit for OpenVMS VAX V5.5-2
o This problem is due to a basic inadequacy in the lock manager
design that manifests itself in two different file system
visible problems. The first is that, from time to time, access
to a cluster shared file is incorrectly denied to an accessor.
That is, an application running on a node of a cluster will
attempt to open (access) a given shared file in what looks to
be a compatible way and will receive an SS$_ACCONFLICT status.
Secondly, again sporadically, an application will create a new
file and the system will crash in CREATE with and XQP bugcheck
whose text reads, 'how can we fail to access a new file'.
Page 8
o When a file is open with a NL mode access lock then an attempt
to access an extension header may fail because the FCB chain is
being rebuilt.
This fix allows an extension file header to be accessed even if
the initial search for the FCB failed.
o During backups BACKUP accesses file extension headers directly
instead of going in under the synchronization of the primary
header. This can lead to the FCBs for the headers which backup
is looking at being deallocated under it's feet by other
processes.
The net result is any number of different XQP bugchecks, most
notably UNXSIGNAL (accvio), NOTFCBFCB and XQPERRs.
This seems to be relatively easy to provoke if you back up the
same disk in two different processes at the same time.
A modification was made earlier to the XQP to fix this lack of
synchronization, however this fix had a timing window in it.
Problems addressed in VAXF11X01_U2055 kit for OpenVMS VAX V5.5-2
o Previously, reading beyond the high water mark of a file
produced inconsistent results. The user's buffer was not
actually modified yet the I/O status returned indicated
success. This problem manifested itself principally when doing
BACKUP/VERIFY of files whose high water mark was less than the
physical filesize. The result was BACKUP issuing error
alarming error messages.
o This problem sometimes causes systems to crash in the file
system at offset REMOVE+4F. It also might cause us to delete
the wrong directory entry and it is also suspected of possibly
causing other types of directory corruption.
Prior to this fix, when the file system received a hardware
write error trying to write a directory data block to disk, the
system sometimes crashed.
o In order to prevent deadlocks, the file system has assigned
certain ranking rules to the various locks that it deals with.
In particular, it is incorrect for the file system to attempt
to acquire the SERIAL lock of a particular file while the file
system holds the ALLOCATION lock for the volume on which the
particular file exists.
o A previous attempt to solve the problem of extending the
INDEXF.SYS file has introduced new problems which resulted in
sometimes leaving the INDEXF.SYS file very fragmented.
Therefore a new simplified algorithm for INDEXF.SYS extending
has been introduced.
Page 9
o During a cluster transition, lock value blocks may normally
become invalid. It is responsibility of lock manager users,
such as the file system to take appropriate action in the face
of invalid value blocks.
o This problem leads to a loss of synchronization that leads to a
system crash which occurs when one processes accesses what
turns out to be an extension header, by FID, at the same time
that that header is being deleted. In the past this same
problem caused a system deadlock resulting in a hung system.
The fix that resolved the deadlock now sometimes results in a
crash.
The file system synchronizes access to files and FCBs by taking
out the serial lock on the primary header of a file. The
problem is that we support access by File ID in some cases, and
if a file ID happens to be an extension file ID, then
determination of the proper lock to use is an interactive
process.
o A problem was reported that performing a certain set of steps
for two different processes running two different images
simultaneously (Image A & Image B):
- 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 will
result in Image B terminating with a SS$_PAGRDERR.
o On a very fragmented disk, creation of a file on a volume could
cause the INDEXF.SYS to become corrupt. The last map pointer
count (from a DUMP/HEADER INDEXF.SYS) in the INDEXF.SYS header
would contain a value of 256. ANALYZE/DISK would report this
as an "invalid map area" error.
o If a nonprivileged user performed a $ SET FILE/NODIRECTORY on a
directory file the user owns, no error was returned, but the
file retained the directory attribute.
o Note that in an allocation failure on a single volume no
corruption is possible from this bug.
Previously, if we tried to extend a file on a bound volume set
and we failed to find enough space to satisfy the request we
would leave a corrupt WCB in memory that could lead to possible
Page 10
data corruption.
o Previously it was possible to attempt to perform a directory
operation on an already corrupt directory without noticing it.
Then when we went to write the directory and found corruption
we would crash the system.
o In the past it was legal to issue a QIO request to extend a
directory and make it non-contiguous. This had negative
side-effects because the file system assumes that directories
are contiguous.
o In the past it was legal to issue a QIO request to lookup a
file in a directory, specified by DID = 1, which would result
in a crash. The problem is that file ID 1 is that of
INDEXF.SYS, which is not a directory, and that due to an error
we did not properly cleanup after discovering the discrepancy.
o There is a problem that may occur on:
- Bound volume sets in non-clustered configurations.
- Bound volume sets on devices that are not available
cluster-wide.
A synchronization error in the XQP may lead to open files
caching stale mapping information for bound volume sets.
If the file is open for write, you may lose file updates or
corrupt disk file contents. Any resulting corruption affects
complete disk blocks.
Kit Installation Rating:
The following kit installation rating, based upon current CLD
information, is provided to serve as a guide as to which customers
should apply this remedial kit. (Reference attached Disclaimer of
Warranty and Limitation of Liability Statement)
INSTALLATION RATING:
1 : To be installed by all customers.
Installation Instructions:
Install this kit with the VMSINSTAL utility by logging into the
SYSTEM account, and typing the following at the DCL prompt:
@SYS$UPDATE:VMSINSTAL VAXF11X03_070 [location of the saveset]
The saveset location may be a tape drive, or a disk directory that
contains the kit saveset.
Page 11
System should be rebooted after successful installation of the kit.
If you have other nodes in your VMScluster, they should also be
rebooted in order to make use of the new image(s).
Copyright (c) Digital Equipment Corporation, 1996 All Rights
Reserved. Unpublished rights reserved under the copyright laws of
the United States.
The software contained on this media is proprietary to and embodies
the confidential technology of Digital Equipment Corporation.
Possession, use, or dissemination of the software and media is
authorized only pursuant to a valid written license from Digital
Equipment Corporation.
DISCLAIMER OF WARRANTY AND LIMITATION OF LIABILITY
THIS PATCH IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND. ALL
EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR
PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED TO THE
EXTENT PERMITTED BY APPLICABLE LAW. IN NO EVENT WILL DIGITAL BE
LIABLE FOR ANY LOST REVENUE OR PROFIT, OR FOR SPECIAL, INDIRECT,
CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND
REGARDLESS OF THE THEORY OF LIABILITY, WITH RESPECT TO ANY PATCH
MADE AVAILABLE HERE OR TO THE USE OF SUCH PATCH.
|