|
HP OpenVMS Systemsask the wizard |
|
The Question is:
We have experienced a serious low space problem on our system disk:
1. Free space on sys$device (system disk) been extremely low (less than
2%)
2. We have attempted reducing the size of SYSDUMP.DMP from 1624878 to
500000 blocks. Note that that value 1624878 been previously assigned by
AUTOGEN as the recommended one.
3. File SYSDUMP.DMP could not been extent to 500000 giving the
following error:
SYSTEM $ mc sysgen create sysdump.dmp /siz=1624878
%SYSGEN-I-PRTEXT, file only partly extended. Volume may be too fragmented
4. Currently SYSDUMP.DMP file been extented to 150000 blocks.
5. DEFRAG could not correct the problem. sys$device fragmentation index
is 85.0 (badly fragmented disk)
1 - 20.9 is excellent
21 - 40.9 is good
41 - 60.9 is fair
61 - 80.9 is poor
81 - 100 indicates a badly fragmented disk
6. Calculating the total amount of disk space used by existing files on
system disk we find out that approximately 2,000,000 blocks are reported to
be used but dont actually exist (lost files/reported to be deleted).
7. SYSTEM $ anal/disk/repair dsa0: show that several files been marked
for deletion but can not be removed. (See below)
8. Running again with the repair qualifier SYSTEM $ anal/disk/repair
dsa0: the problem could not been resolved.
Considering that backup/restore may not fix the problem since /IMAGE backup
attempts to save or copy all files on the input disk volume including files
marked for deletion and lost files, are there any alternative options to
correct the problem?
Best Regards,
Mirtos Anastasiades
SYSTEM $ anal/disk/repair dsa0:
Analyze/Disk_Structure/Repair for _DSA0: started on 27-APR-1999 02:05:07.50
%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
-SYSTEM-W-NOSUCHFILE, no such file
%ANALDISK-W-DELHEADER, file (8594,63,1) DMQ$SERVER_TEMP_0000021C.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (8626,23,1) DMQ$SERVER_TEMP_00000220.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (8650,71,1) DMQ$SERVER_TEMP_00000222.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (8744,7,1) DMQ$SERVER_TEMP_00000223.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (8838,24,1) DMQ$SERVER_TEMP_0000021C.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (8949,37,1) DMQ$SERVER_TEMP_0000022A.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (9003,14,1) DMQ$SERVER_TEMP_0000022C.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (9020,143,1) DMQ$SERVER_TEMP_0000022D.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (9032,19282,1) DMQ$SERVER_TEMP_0000021C.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (9072,158,1) DMQ$SERVER_TEMP_00000234.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (9143,823,1) DMQ$SERVER_TEMP_00000236.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (9151,76,1) DMQ$SERVER_TEMP_00000237.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (9170,444,1) DMQ$SERVER_TEMP_0000021C.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (9204,59,1) DMQ$SERVER_TEMP_0000023D.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (9225,17,1) DMQ$SERVER_TEMP_0000023F.COM;1
marked for delete
%ANALDISK-W-DELHEADER, file (9232,9,1) DMQ$SERVER_TEMP_00000240.COM;1
marked for delete
SYSTEM $
The Answer is :
You will need to unload the contents of your system disk to tape and
then reload them -- BACKUP/IMAGE via the bootable environment on OpenVMS
Alpha, and BACKUP/IMAGE via standalone BACKUP on OpenVMS VAX. This
will defragment your system disk. (Your concerns around files marked
for deletion and lost files are likely unfounded -- ANALYZE/DISK/REPAIR
does correct these, save for active files.)
You will seriously want to consider acquiring and migrating to a larger
system disk. You do not indicate which system disk is in use, but it
is clearly insufficient for your current requirements.
You may want to consider moving local non-system functions and local
tools off the OpenVMS system disk.
You will want to consider upgrading to a version of OpenVMS Alpha that
supports configuring the dump file off the system disk (DOSD).
When calculating disk storage, remember that using DIRECTORY on a system
disk (or any disk with directory aliases) will show erroneously high
values for usage. DIRECTORY does not take into consideration any alias
entries, and the alias directory entries present on OpenVMS system disks
cause very large free space discrepencies from the storage reported by
SHOW DEVICE/FULL.
If you feel you can live with a 500,000 block dump file, you could try
the following sequence:
o Create the largest dump file you can. (Say, 150,000 blocks?)
o Set the DUMPSTYLE parameter to deal with the size of the dump file,
using an entry in SYS$SYSTEM:MODPARAMS.DAT, and an AUTOGEN pass.
o Shut down and then reboot the system minimum ("b -fl 0,1" to get
to the conversational boot (SYSBOOT) prompt, then SET STARTUP_P1
"MIN", then SET WRITESYSPARAMS 0, and then CONTINUE).
o Log in, then purge SYSDUMP.DMP.
o Create a new SYSDUMP file of the appropriate size, assuming
sufficient free space was freed by purging the old file.
o Reboot.
o Log in, then purge SYSDUMP.DMP again.
This is a short-term option and may or may not operate. It is no
substitute for the BACKUP/IMAGE and restoration to defragment the
system disk.
|