[fa.info-vax] Recovering contiguous disk space

info-vax@ucbvax.ARPA (07/03/85)

From: VENARD%EDUCOM.BITNET@WISCVM.ARPA

What is the best way to recover contiguous space on a Winchester disk
pack?  I remember hearing that there are problems in VMS Version 4.0,
in which files can be lost or corrupted if the pack they are on is heavily
fragmented.  The largest contiguous free space on our CDC 9730 (emulates
an RM80) is only 448 blocks.

VENARD@EDUCOM

info-vax@ucbvax.ARPA (07/03/85)

From: "DAVID DRAKE" <drake@paxrv-nes>

Have I Got a nightmare for you ...

We are runing a VAX 11/730 with an R80 (121 Mb) as a system disk (V4.1).
Turns out one evening I asked for 10k blocks contiguous space and
was refused.  Noting that I had 50k free blocks, decided that I
should go ahead and backup the sytem.  I used standalone and backed
up the system and restored it using the INIT on the R80 on the return
trip.  Well, was I ever amazed when I booted the new system and found
out when I tried to run the old DECUS routine, DISKSPACE, that it
could not open the tmp file it needed.  I did a SHOW DEV/MOUNT and
had zero freeblocks.  Horror ....  What happened to my 50k.  Where 
was the 5 to 10k I should have picked up in the packing of the
disk.  Well, I deleted some big files to allow for some space as
the Lab was closing and came in the next morning late due to alot
of MURPHY jobs.  I had called the Rocky Mnt High folks (DEC support)
and they were baffled.  I did not get back to the problem until
the next nite and decided that I would run ANALYZE/DISK/REPAIR and
see if it could find my lost space.  Like a dummy I ran it from
my VT240 (so i had no hardcopy) but I did see a recover msg that
blocks umptiump to umptiump (about 55k) were "incorrectly addressed."
I thought that the prob was solved but still the space did not show
up as free space.  Calling around my area in desperation, talking with
the local VMS hacks in my LUG, the best I could come up with was
'boot the bit__'.  So I booted and low and behold ... I had 50k
freespace.

	Now the real horror started the next day in that I found out
tht every file which had been created since the snafu was in never
never land.  I could look at the directories .... ie did a DIR/DATE/
SINCE='time I had rebooted' ..... and found all the files which
were bad.  But when any of these were access ... an error of not being
able to locate the file (BAD LBN=0) was reported.  I called Rocky Mtn
High again and they said that the only way to recover the files was to
QIO and .....   Well, not being at that kind of level in programming
on this bear .... I wound up deleteing all the files and recovering
most of them from a previous backup.  What I did lose was the MAIL
files for those two days ... 34 of them.  Whole MAIL areas were 
destroyed.  

	If I had it to do over again .... i'll have to be desperate
for contigous space. I would do the following:

		Backup up the disk
		Restore the disk
		Run ANAL
		Reboot

Good luck ....

P.S.  DEC felt realy baffled and in desperation they sent a fix on the
       F11BXQP.EXE module that will be part of the 4.2 as I understand
       it .... but I am convinced that it had nothing to do with this
       problem.  They also claimed that I should not have used the INIT
       on the return qualified of backup.  

Drake@paxrv-nes.arpa
------